amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > "Speicherschutz durch sichere Sprachen" [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

20.03.2002, 15:09 Uhr

Solar
Posts: 3680
Nutzer
In einem Kommentar-Thread provozierte "future68k" mit der Behauptung, man solle doch in Zukunft den Speicherschutz aus dem Betriebssystem herauslassen und statt dessen nur noch "sichere" Programmiersprachen zulassen. Als Beispiele nannte er Java, Perl, Ruby und Rebol.

Ich antwortete, das auch Renten und der ICE mal als "sicher" galten - future68k tat das als Wortspiel ab.

Mal abgesehen davon, daß ich nicht einsehe, wie eine interpretierte Sprache (auch mit JIT) gegenüber einer Speicherschutz-Architektur mit nativem Kompilat schneller / besser sein soll

http://www.heise.de/newsticker/data/kav-20.03.02-000/ - "Java-Sicherheitslücke weitet sich aus".

Soviel zum Thema "Sicherheit durch Sandboxing".

[ - Antworten - Zitieren - Direktlink - ]

22.03.2002, 09:34 Uhr

ylf
Posts: 4112
Nutzer
Absolute Sicherheit ist eine Illusion, oder?

bye, ylf

[ - Antworten - Zitieren - Direktlink - ]

22.03.2002, 11:24 Uhr

DrNOP
Posts: 4118
Nutzer
... aber man muß das unmögliche fordern, um das mögliche zu erreichen. :P

[ - Antworten - Zitieren - Direktlink - ]

22.03.2002, 13:29 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von ylf:
Absolute Sicherheit ist eine Illusion, oder?


Ja, und zwar sowohl bei MMU-Speicherschutz wie auch beim Sandboxing. Mit dem Unterschied, das CPUs dafür gebaut werden, MMU-Speicherschutz zu bieten, und das Sandboxing nur mit einer begrenzten Auswahl von Programmiersprachen geht - für Konzerne und Softwarefirmen eine i.d.R. nicht akzeptable Einschränkung.

[ - Antworten - Zitieren - Direktlink - ]

22.03.2002, 18:47 Uhr

Holger
Posts: 8116
Nutzer
Der zitierte Artikel hat eine total effekthaschende Überschrift, die mit dem tatsächlichen Artikel überhaupt nichts zu tun hat. Die konzeptionelle Sicherheit wird davon überhaupt nicht berührt und die tatsächliche Sicherheit hat sich ja somit gerade erhöht, denn eine weitere Lücke ist bekannt geworden und kann somit geschlossen werden.
Code-Verification ist im Endeffekt genauso sicher, wie MMU-basierter Speicherschutz und von der Qualität der Implementierung abhängig. Welcher Mechanimus eine höhere Performance bietet hängt einfach vom speziellen Anwendungsfall ab.

Der ursprüngliche Ausgangspunkt im Kommentarforum, war aber das alte Statement von AInc, das DE könne ohne konventionellen Speicherschutz auskommen, ohne ein konkretes Statement, wie das aussehen solle. Später hat AInc dann mal was von sicheren Sprachen phantasiert, und da stimme ich Solar voll zu, daß das nicht funktioniert.

Und Sprüche ala "benutzt eure Kreativität" sind totaler Unfug. Es ist mir zwar klar, daß AInc gerne eine Lösung und am besten fertige Implementation aus der "Community" hätte, aber Schutzmechanismen, egal welcher Art können nicht im nachhinein implementiert werden. Und Programm A in einer abgeblockten Umgebung auszuführen nützt überhaupt nichts, wenn weiterhin Programm B aus beliebiger Quelle machen kann, was es will.

Und Elate wird nicht in sicheren Sprachen programmiert. Für Java ist noch nicht mal ein Compiler mitgeliefert. Die gehypte Sprache ist VP-Assembler und die einzig verfügbare vernünftige Sprache ist C/C++ mit schlechten Header-Files. Beides keine sicheren Sprachen.

mfg

--

Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

25.03.2002, 09:13 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von Holger:
Der zitierte Artikel hat eine total effekthaschende Überschrift, die mit dem tatsächlichen Artikel überhaupt nichts zu tun hat. Die konzeptionelle Sicherheit wird davon überhaupt nicht berührt und die tatsächliche Sicherheit hat sich ja somit gerade erhöht, denn eine weitere Lücke ist bekannt geworden und kann somit geschlossen werden.


Eine sehr optimistische Auslegung, die auch Windows / Outlook / Internet Explorer mit jedem Patch "sicherer" werden läßt.

Es ging mir dabei nur um den empirischen Beweis, das eine Sandbox auch Lücken haben kann - und nach Murphy auch haben wird.

Zitat:
Code-Verification ist im Endeffekt genauso sicher, wie MMU-basierter Speicherschutz und von der Qualität der Implementierung abhängig.

Ich sehe aber schon einen Unterschied in einer Code-Verification auf einer noch zu entwickelnden Minderheitenplattform und den Hardware-Mechanismen in industrieweit verwendeten Prozessoren. Letztere im Kernel "sauber" zu unterstützen dürfte einfacher sein. IMHO allerdings.

Zitat:
Welcher Mechanimus eine höhere Performance bietet hängt einfach vom speziellen Anwendungsfall ab.

Hier wage ich zu widersprechen. Der Performance-Unterschied zwischen "mit/ohne MMU-Speicherschutz" und "interpretierte/Bytecodesprache / compilierte Sprache" ist doch wohl eine andere Größenordnung, ganz unabhängig von der Anwendung.

Zitat:
Der ursprüngliche Ausgangspunkt im Kommentarforum, war aber das alte Statement von AInc, das DE könne ohne konventionellen Speicherschutz auskommen, ohne ein konkretes Statement, wie das aussehen solle.

Nicht ganz - future68k propagierte das "Speicherschutzlose OS das nur 'sichere Sprachen' zuläßt" als ganz allgemein das überlegene Konzept...

Zitat:
Und Elate wird nicht in sicheren Sprachen programmiert. Für Java ist noch nicht mal ein Compiler mitgeliefert. Die gehypte Sprache ist VP-Assembler und die einzig verfügbare vernünftige Sprache ist C/C++ mit schlechten Header-Files. Beides keine sicheren Sprachen.

Eben.

[ - Antworten - Zitieren - Direktlink - ]

25.03.2002, 11:49 Uhr

MrMarco
Posts: 445
Nutzer
Zitat:
Original von Solar:
Nicht ganz - future68k propagierte das "Speicherschutzlose OS das nur 'sichere Sprachen' zuläßt" als ganz allgemein das überlegene Konzept...


Hehehe... du kennst mich... Er soll mir eine Sprache nennen die diesen Anspruch erfüllt und ich zeige ihm auf Anhieb min. 10 Problemstellen und Möglichkeiten wie man diesen Mechanismus durch Leichtsinnigkeitsfehler aushebeln kann.

Sowas gehört definitiv ins OS!

Es gibt IMMER min. 1 Weg solche Mechanismen auszuhebeln. Aber wenn das OS das von sich aus abfängt und man versucht es trotzdem... hmmm... man reiche mir eine alte Blutig Rostige Stumpfe Säge und den Hals dieses Programmierers damit ich mit ihm mal die Do's and Dont's durchgehen kann... :)

MfG
MrMarco

[ - Antworten - Zitieren - Direktlink - ]

25.03.2002, 14:22 Uhr

Solar
Posts: 3680
Nutzer
Wie gesagt, die Liste war Java, Perl, Ruby, und Rebol. Nun hat future68k das Glück gehabt, das ich mich in letzteren dreien nicht auskenne und in ersterer eher versuche, produktiven Code zu erzeugen statt Sicherheitslücken auszutesten, also konnte ich keinen "MalCode" aus der Hüfte zaubern.

[ - Antworten - Zitieren - Direktlink - ]

25.03.2002, 14:53 Uhr

MrMarco
Posts: 445
Nutzer
Zitat:
Original von Solar:
Wie gesagt, die Liste war Java, Perl, Ruby, und Rebol. Nun hat future68k das Glück gehabt, das ich mich in letzteren dreien nicht auskenne und in ersterer eher versuche, produktiven Code zu erzeugen statt Sicherheitslücken auszutesten, also konnte ich keinen "MalCode" aus der Hüfte zaubern.


Perl... hmmm... Perl hat keine Funktion mit der ich Speicher gezielt anfordern kann. Falls das Nichtvorhandensein dieser Funktion das einzigste ist was Speicherschutz bieten soll, dann finde ich es erbärmlich!

Btw... bei Perl kann man locker Buffer-Overflows erzeugen. Gibt einige feine Scripte dafür! :)

Damit kann man ganz nett Webpages zum crashen bringen.

Da das aber ein Problem des dahinter liegenden OS ist, gehört JEDE dieser Sprachen zu der Sorte "Total unsicher" :)

Also wieder nix für ihn :)

Irgendwie hab ich das Gefühl der Bub hat gar keine Ahnung wovon er da eigentlich redet, oder? /me kann sich noch an die 8Bit Zeiten erinnern wo man einen Trackloader in Assembler noch per Hand auf dem Papier gecodet hat, oder ein Snake-Game in 1 KB untergebracht wurde...

MfG
MrMarco

[ - Antworten - Zitieren - Direktlink - ]

26.03.2002, 07:10 Uhr

ylf
Posts: 4112
Nutzer
8-Bit-Zeiten? Das war vorm Amiga ;)
8085 oder so ... :D
Das Teil konnte ja noch nicht einmal multiplizieren.

bye, ylf

[ - Antworten - Zitieren - Direktlink - ]

26.03.2002, 10:14 Uhr

Solar
Posts: 3680
Nutzer
Never forget the 6502... ;-)

[ - Antworten - Zitieren - Direktlink - ]

26.03.2002, 11:25 Uhr

MrMarco
Posts: 445
Nutzer
Zitat:
Original von ylf:
8-Bit-Zeiten? Das war vorm Amiga ;)
8085 oder so ... :D
Das Teil konnte ja noch nicht einmal multiplizieren.


6502 rulez! 6502C sogar.

Das waren Zeiten. Da hat man wirklich alles noch per Hand gemacht und es ging auch! Schwärm...

MfG
MrMarco

[ - Antworten - Zitieren - Direktlink - ]

26.03.2002, 14:04 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Das Teil konnte ja noch nicht einmal multiplizieren.

Rein prinzipiell kann das eh keine CPU, genausowenig wie dividieren oder subtrahieren. Die können eigentlich nur eines: verdammt schnell addieren, der Rest kann dann darauf zurückgeführt werden... ;-)


[ - Antworten - Zitieren - Direktlink - ]

26.03.2002, 16:37 Uhr

Psyco_F
Posts: 201
Nutzer
nein, ganz genau genommen kann sie nicht mal addieren und subtrahieren, sondern nur logische Verknüpfungen (aufgrund der Bool'schen Algebra) auf Hardwareebene, und alles kann darauf zurückgeführt werden.

*mit Wissen protz* :D :D :D

[ - Antworten - Zitieren - Direktlink - ]

26.03.2002, 20:59 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Solar:
Zitat:
Das Teil konnte ja noch nicht einmal multiplizieren.
Rein prinzipiell kann das eh keine CPU, genausowenig wie dividieren oder subtrahieren. Die können eigentlich nur eines: verdammt schnell addieren, der Rest kann dann darauf zurückgeführt werden... ;-)
Heutige Multiplikationseinheiten arbeiten nicht mehr mit Addition. Man kann natürlich einen gewissen Anteil Addition hineininterpretieren, weil die Einheit auf ähnlichen Logikbausteinen aufbaut, wie die Additionseinheiten. Prinzipiell ist es aber schon lange kein n-Mal aufaddieren mehr.

mfg

--

Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

26.03.2002, 21:14 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Solar:
Es ging mir dabei nur um den empirischen Beweis, das eine Sandbox auch Lücken haben kann - und nach Murphy auch haben wird.

Wie ich sagte, das ist eine implementationsspezifische Sache. Das sagt aber eben überhaupt nichts über die prinzipielle Qualität der Sache aus. MMU-basierter Speicherschutz kann genauso fehlerhaft sein, siehe Windows.
Zitat:
Ich sehe aber schon einen Unterschied in einer Code-Verification auf einer noch zu entwickelnden Minderheitenplattform und den Hardware-Mechanismen in industrieweit verwendeten Prozessoren. Letztere im Kernel "sauber" zu unterstützen dürfte einfacher sein. IMHO allerdings.
Wie schon oben gesagt, siehe Windows. Jeder Mechanismus kann fehlerhaft implementiert werden. Und die MMU alleine macht eben noch keinen Speicherschutz. Schließlich haben etliche Amigas ebenfalls eine MMU.
Und ich mache hier auch einen deutlichen Unterschied zwischen Systemen wie Java-VM/Bytecode, der verifizierbar ist, weil er von Anfang an darauf ausgelegt sind und bestimmte Operationen gar nicht kennt, und Elate/VP, das dafür überhaupt nicht ausgelegt ist, und dessen Architektur entsprechende Zugriffe auch gar nicht als illegal definiert.
Zitat:
Hier wage ich zu widersprechen. Der Performance-Unterschied zwischen "mit/ohne MMU-Speicherschutz" und "interpretierte/Bytecodesprache / compilierte Sprache" ist doch wohl eine andere Größenordnung, ganz unabhängig von der Anwendung.
Wir reden hier nicht über interpretierte Sprachen. Wir reden wennschon über laufzeitoptimierte mixed-mode Umgebungen. Die können den Overhead durchaus in die gleiche Größenordnung wie MMU bringen, allerdings natürlich nicht auf dem Desktop, wo dieser Overhead zusätzlich zum OS-Schutzsystem entsteht. Deshalb betonte ich das anwendungsabhängige Element.

mfg

--

Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

30.05.2002, 09:30 Uhr

future68k
Posts: 1
Nutzer
hallo,

> In einem Kommentar-Thread provozierte "future68k" mit der Behauptung,
man solle doch in Zukunft den Speicherschutz aus dem Betriebssystem
herauslassen und statt dessen nur noch "sichere" Programmiersprachen
zulassen. Als Beispiele nannte er Java, Perl, Ruby und Rebol.

das stimmt, provozieren wollte ich aber auch mich selber. mir dient
das der meinungsbildung, und ich bin noch keineswegs restlos sicher,
dass die idee gut ist.

> Irgendwie hab ich das Gefühl der Bub hat gar keine Ahnung wovon er
da eigentlich redet, oder?

nur zu, pack das beilchen aus und starte das schlachtfest. ich habe
mich hier angemeldet, um ideen zu entwickeln. davon abgesehen, der
klügere gibt niemals nach, und ich lasse mich jederzeit gerne
provozieren :)

okay, hier erstmal ein interessanter artikel:
http://www.linuxjournal.com/article.php?sid=6105&mode=thread&order=0


autor und umfeld sind gewiss nicht über jeden verdacht erhaben, aber
der artikel enthält interessante ideen. hier nochmal eine unsachliche
zusammenfassung, bereits verzahnt mit meinen subjektiven
schlussfolgerungen... provokation im anmarsch:

microkernel-designs mit speicherschutz sucken. userspace-prozesse
müssen massiv die MMU-barriere mit messaging durchtunneln.
monolithische kernel mögen zwar unästhetisch sein, aber im kernelspace
können viele layer ohne MMU-barriere interagieren. monolithische
designs sind für heutige prozessoren mit ihrem aufwendigen überbau an
cache-architektur generell effizienter. TCP-stacks, als beispiel
angeführt, sind notorisch langsam auf microkernel-betriebssystemen,
bzw. wenn sie als userspace-prozesse implementiert sind.

ich hatte einmal die gelegenheit, einem microkernel-workshop
beizuwohnen, bei dem es um die klärung der frage ging, wie man dem
hurd OS einen neuen microkernel spendieren könnte. ursache: hurd ist
ebenfalls auf mach aufgesetzt, und hurd ist langsam - so langsam, dass
es selbst den entwicklern irgendwann auffiel. der workshop endete in
einer katastrophe; der hurd-repräsentant offenbarte seine unkenntnis
über die genaue latenz für message-passing über prozessgrenzen hinweg:
"slow". dabei dürfte genau DIES zehntausende mal pro sekunde auftreten
und ursächlich dafür verantwortlich sein, dass hurd kriecht.
(darüberhinaus war er natürlich nicht willens, auf implementierungen
der microkernel-architektur einzugehen, die nicht der GPL
unterstanden. traurig, aber aufschlussreich!)

das bringt mich zu der frage zurück, warum der texteditor auf meinem
amiga smooth scrollt, während ich beispielsweise über NFS kompiliere
und nebenher eine CD brenne. oder warum I/O unter linux so
merkwürdiges performance-verhalten aufweist, wie beispielsweise, dass
beim brennen einer CD der desktop ruckelt und stottert; weil die daten
über den IDE- auf den SCSI-bus gelangen müssen? oder überhaupt erst,
warum alles, was irgendwie schnell sein soll, dann doch über shared
memory gelöst werden muss. wer sich beispielsweise die #%$?! API für
XShm anschaut, verflucht speicherschutz nachhaltig: eine latte
semaphoren und permissions anfordern, ein halbes dutzend handles und
flags mit sich herumschleppen, himmela****, ich wollte doch nur ein
RGB-array ausnahmsweise mal nicht über einen socketdeskriptor
schreiben. (ja, gewiss, das ist auch ein spezifisches problem der
X-architektur. die windows-APIs zeigen, dass es auch eleganter geht.)

was also führt zu dem ganzen architekturellen bloat? ich sage, es sind
die MMU-layers für speicherschutz und virtual memory. dass es für
anwenderbelange besser geht, hat das amigaos bewiesen. in seiner
speziellen weise ist es perfekt: ein microkernel-design, vollständig
basierend auf message-passing, gewiss, aber message passing hat
grundsätzlich zero overhead, und die MMU wird in der elegantesten
denkbaren weise verwendet, d.h. vollständig ignoriert. weil man ein
reines anwenderbetriebssystem vor sich hat, weiss man, worauf man sich
dabei einlässt: ist die software buggy, folgt unweigerlich der
affengriff - also besser vorher speichern.

mit dem affengriff mag sich nun keiner mehr anfreunden. ich propagiere
daher nachhaltig, OS- und applikationsaufgaben konzeptionell zu
trennen, aber nicht notwendigerweise in der implementierung. aufwendig
errichtete wälle für paging, permissions und speicherschutz gaukeln
sicherheit nur vor und sind in erster linie der performance
abträglich. das konzept stammt klar aus einer zeit, da fast alles in
pointersprachen programmiert wurde.

diese performance könnte aber viel sinnvoller in higherlevel-sprachen
für applikationsaufgaben verbraten werden, nämlich dort, wo der
performance-verlust mit etwas viel sinnvollerem als schnödem
speicherschutz eingetauscht wird: abstraktion. dafür könnten dann
applikationen und higherlevel services in einem pool von shared memory
laufen und blitzschnell daten austauschen. (UND ZWAR OHNE RUCKELN UND
STOTTERN, wie es bei monolithischen designs fast unausweichlich ist,
weil die I/O-master-schnittstelle single-threaded ist.)

alles, was schnell sein muss, würde weiterhin in C/C++/asm
programmiert. oder wem sollte das nützen, dass eine "schutzverletzung"
angezeigt würde, weil das filesystem oder ein gerätetreiber buggy ist?
bei einem TCP-stack, der willenlos im speicher rumsägt, kann man das
OS getrost als ganzes auf den mülleimer ziehen. was schnell sein muss,
muss in aller regel auch fehlerfrei sein, speicherschutz hin oder her.
wenn man entwickler eines superschnellen 3d-shooters ist, was spricht
dagegen, sich bei einer zentralen registratur zertifikat/ID/namespace
zur installation der kernroutinen als native library zu besorgen?
diese lib könnte nach gründlichem testen und nach zertifizierung nativ
ausgeführt werden.

gruss
future68k

[ - Antworten - Zitieren - Direktlink - ]

30.05.2002, 14:29 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von future68k:
microkernel-designs mit speicherschutz sucken. userspace-prozesse
müssen massiv die MMU-barriere mit messaging durchtunneln.
monolithische kernel mögen zwar unästhetisch sein, aber im kernelspace
können viele layer ohne MMU-barriere interagieren.

Du vergißt, daß letztendlich immer eine Anwendungssoftware auf diese Layer zugreifen muß, schließlich ist ein Kernel kein Selbstzweck.
Zitat:
das bringt mich zu der frage zurück, warum der texteditor auf meinem
amiga smooth scrollt, während ich beispielsweise über NFS kompiliere
und nebenher eine CD brenne. oder warum I/O unter linux so
merkwürdiges performance-verhalten aufweist, wie beispielsweise, dass
beim brennen einer CD der desktop ruckelt und stottert; weil die daten
über den IDE- auf den SCSI-bus gelangen müssen?

Damit widersprichst Du ja gerade der o.g. Theorie, daß ein monolithischer Kernel effizienter wäre. Tatsache ist, daß das IO-System auf einer Dose überhaupt nichts mit Speicherschutz zu tun hat, im Gegensatz zum Amiga ist das wenigste Memory-Mapped IO. Der PC ist ein übler Interrupt-Generator und die Performance von Pipeline-Architekturen, wie Prozessor, geht bei Interrupts prinzipbedingt in die Knie.

mfg

--

Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > "Speicherschutz durch sichere Sprachen" [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.