|
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.  [ - Antworten - Zitieren - Direktlink - ] |
|
22.03.2002, 13:29 Uhr Solar Posts: 3680 Nutzer |
Zitat: 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: 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: 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: 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: Nicht ganz - future68k propagierte das "Speicherschutzlose OS das nur 'sichere Sprachen' zuläßt" als ganz allgemein das überlegene Konzept... Zitat: Eben. [ - Antworten - Zitieren - Direktlink - ] |
|
25.03.2002, 11:49 Uhr MrMarco Posts: 445 Nutzer |
Zitat: 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: 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 ...  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: 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: 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* [ - Antworten - Zitieren - Direktlink - ] |
|
26.03.2002, 20:59 Uhr Holger Posts: 8116 Nutzer |
Zitat: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: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: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: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:Du vergißt, daß letztendlich immer eine Anwendungssoftware auf diese Layer zugreifen muß, schließlich ist ein Kernel kein Selbstzweck. Zitat: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. |
|