Suche - amiga-news.de Forum

amiga-news.de Forum > Suche

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

Ergebnisse der Suche: 1 Treffer (30 pro Seite)

future68k Nutzer

30.05.2002, 09:30 Uhr

[ - Direktlink - ]

Thema: "Speicherschutz durch sichere Sprachen"
Brett: Programmierung

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

-1-

Ergebnisse der Suche: 1 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter			Benutzername
Suchoptionen
	Nur in diesen Foren suchen	nur ganze Wörter Nur Titel anzeigen alle Treffer anzeigen