[HaBo]

Open_Geek

Anzeige

Hallo an alle (vor Allem an die Unix-Nutzer),
ich wollte mal eine Diskussion zu einem beliebten Streitpunkt der Betreibssystementwicklung starten.
Was findet ihr besser: Microkernel oder monolithischer Kernel?
Ich bin schon gespannt auf das Ergebnis

bitmuncher

Dass monolithische Kernel ab einer gewissen Größe kaum noch überschaubar sind, beweist Linux in letzter Zeit zur Genüge. Es schleichen sich mehr und mehr Sicherheitslücken ein, weil Module auf die auf interne Funktionen des Kernels zugreifen können, anstatt über klar definierte Schnittstellen mit diesem zu kommunizieren. Die Wartbarkeit des Codes leidet darunter, wenn uralte Schnittstellen existieren, die kaum noch genutzt und noch seltener bei Code-Reviews in Augenschein genommen werden. Monolithische Kernel machen daher nur Sinn, wenn eh nur eine begrenzte Menge an Hardware, Protokollen, Dateisystemen etc. unterstützt werden müssen, der Code also im Wachstum begrenzt ist.

__________________

Open_Geek

Genau das habe ich kürzlich beim Durchsehen des Linux-Sourcecodes auch bemrkt. Ich habe ein Projekt von GNU gefunden, das zwar schon ewig existiert und das ja auch der Anfang von GNU war: den GNU Mach(der Microkernel für das GNU-Operating-System) und die Serversammlung dafür, den GNU Hurd. Es gibt auch schon ein Debian/GNU Hurd.
Ich habe diese Umfrage gestartet, weil ich wissen wollte, ob es sich lohnt, bei dem GNU/Hurd mitzuarbeiten, da sich das Projekt noch in der Entwicklungsphase befindet. Der Sourcecode ist jedenfalls sehr viel übersichtlicher(und daher auch leichter verbesserbar)als bei Linux, das merkt man schon beim ersten Lesen. Ich hoffe, es kommen weiter Meinungen dazu!

RedEagle

Bei einem PC ist ein Microkernel auf jeden Fall sehr empfehlenswert. Er ist leichter zu plege, komponengten lassen sich leichter vollständig austauschen und die sind deutlich flexibler. Es gibt so viel verschiedene Hardware-komponenten für PCs, aber wer hat die schon alle bei sich zu Hause. Warum sollte man dann für alles Treiber an Bord haben. Das verursacht nur instabilität, unsicherheit und geschwindigkeits-einbußen.

Außerhalb von Computern halte ich monolithische Kernel aber für durchaus sinnvoll. Vor allem bei kleingeräten wie mp3-playern, Navigationsgerätzen o.ä. Hier Läuft das System auf immer gleichen Geräten, oder welchen die sich nur minimal unterscheiden. Auch ist die Anzahl der nötigen Treiber deutlich geringer.

Naja, ich habe meine Stimme jedenfalls für den Microkernel abgegeben Für den PC ist das Konzept auf jedenfall deutlich besser geeignet als ein monolithischer

beavisbee

*dafür*

bitmuncher

Also mir stellt sich bei der Mitarbeit bei einem Projekt eher selten die Frage ob es sich lohnt. Viel wichtiger ist doch: Würde es dir Spass machen? Siehst du deine Interessen in dem Projekt vertreten (also hälst du einen Microkernel für eine gute Sache)?

__________________

Open_Geek

Klar würde es mir Spass machen, sonst hätte ich wahrscheinlich gar nicht nach eurer Meinung gefragt
Ich habe auch geglaubt, dass ein Microkernel ein hohes Potenzial hat, aber ich wollte mich trotzdem mal erkundigen, falls ich (mal wieder) falsch liegen sollte.

CDW

Imho wurde(und wird immer noch) den Microkerneln zu wenig Aufmerksamkeit geschenkt. Zu den Nachteilen des monolytischen Kernels wurde schon zur genüge gesagt - und das wurde afaik vom Tanenbaum seit Jahrzehnten gepredigt[0]
Nur weil mono-Kernel mal bei <100 Mhz CPUs schneller lief, muss man sich nicht ewig daran festhalten . Sein Vorzeigesystem Minix wird zwar immernoch "kritisiert" - aber mal ehrlich, bei der Entwicklermenge Minix vs. Entwicklermenge *Nix machen die meisten "Praxistauglichkeitsvergleiche" keinen Sinn.

Das (theoretisch) beste an Microkerneln: für den Kernel selbst lässt sich die Fehlerfreiheit relativ einfach nachweisen:
Ich wäre eigentlich auch dafür, bei Kerneln&Co endlich mal von C abzukehren (es wird sowieso Zeit für eine modernere Low-Level-Sprache), aber das wäre wohl zu viel verlangt

[0]http://groups.google.com/group/comp....47530d082cd95d

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

xrayn

Formal bewiesene Systeme bringt keine zusätzliche Sicherheit. Zum einen weil nur Dinge bewiesen wurden, die vorher spezifiziert wurden, zum anderen weil man eine Reihe von Annahmen trifft, wie: Compiler arbeitet korrekt oder das die Hardware korrekt funktioniert. Das beide Annahmen falsch sind, hat die Vergangenheit gezeigt und da macht es nichts, wenn formal bewiesen wurde, dass der Kernel keine Integeroverflows besitzt, diese aber durch einen Hardwarefehler produziert werden können. Wenn ein solcher Kernel benutzt werden soll, wird man nicht umhinkommen, dass Software von Dritten erlaubt, welche dann wieder ein erhebliches Sicherheitsrisiko mit sich bringen.

Außerdem wurden nur 7500/8700 Zeilen bewiesen

enkore

Kommentare, Präprozessoren etc. können in den 8700 Zeilen noch drin sein, steht da ja nicht

__________________

"It is the human race! The deterioration of the spirit of man. Man undermining himself, causing a self-willed, self-imposed, self-evident self-destruction."

+++ BREAKING +++ Troll ertrinkt im Planschbecken +++

xrayn

Nein, es ging wirklich um die Zeilen an Code. Es wurde gesagt, dass diese Zeilen lediglich dafür zuständig seien, dass das System überhaupt bootet. Da dieser Code nur einmalig ausgeführt wird, wahr er es nicht wert bewiesen zu werden. Und genau solche Annahmen führen früher oder später dann doch zu Bugs

CDW

Naja, das wäre schon mal ein guter Start, wenn man zumindest teilweise Entwurfsfehler/Implementierungen ausschließen kann . Allgmein hält sich der Kernelcode doch sehr in Grenzen, was das auditen ziemlich erleichtern sollte.

Bei Hardware lässt sich eher nichts machen, aber ein Stichwort zum Compiler wäre Ada & Compilervalidierung (*denkt gerade an "gcc -O3" * )

Und allgemein denke ich bei Micorkerneln nicht nur an "anit-rooting" Sicherheit, sondern auch an ganz normale Systemstabilität

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

bitmuncher

Genau das sprichst du den springenden Punkt an. Ein kleiner Kernel beinhaltet schon aufgrund der Menge des Codes weniger potentielle Fehlerquellen und weniger Angriffspunkte. Das kommt sowohl der Systemsicherheit als auch der Systemstabilität sehr zugute. Unter monolithischen Systemen wie Linux kann jeder x-beliebige Treiber einen Kernel-Crash verursachen, Rechte umgehen etc., was bei einem Microkernel nicht mehr so einfach zu machen ist, da alles, was darauf aufsetzt, klar definierte Schnittstellen nutzen muss. Sind diese sauber definiert, kann ein Treiber kaum noch Schaden verursachen. Um das zu verstehen braucht man auch keine großartigen mathematischen Beweise. Da reicht etwas gesunder Menschenverstand und technisches Verständnis.

__________________

GrafZahl

auch nicht zu verachten ist die tatsache dass das nachladen von modulen selbst zum sicherheitsproblem werden kann, wenn ein solches modul jemandem "untergejubelt" wird ...

microkernel habe unstrittig den architekturvorteil, dass man über die schnittstellen das ganze recht sauber halten kann, und der kern selbst besser überwacht werden kann ... wenn man nun noch eine digitale signatur für module verbindlich fordert und nach dem signieren der module den signaturschlüssel vernichtet, oder zumindest physikalisch aus der zugriffsreichweite entfernt (datenträger im tresor, etc.) hat man schon eine menge getan um es einem angreifer zu erschweren code mit kernel rechten auszuführen

__________________

Code:

:(){ :|:& };:

Veritas Aequitas

enkore

Eins vorweg: Ja ich weiss, dass der NT-Kernel monolithisch ist (mehr oder weniger), ...


... aber dé facto haben wir bei der aktuellen Revision (NT 6.1) schon einige der hier angesprochenen Punkte teilweise umgesetzt:
-Signaturzwang für Treiber, momentan noch deaktivierbar, aber ich gehe davon aus, dass bei spätestens der übenächsten Windowsversion man den Kernel cracken muss um den Signaturzwang zu umgehen
-Zumindest einige Treiber (bspw. Grafikkartentreiber) können unter NT 6.1 das System beim Ableben am Leben lassen. Funktioniert noch nicht ganz excellénte, aber schon recht ordentlich.

Definierte Schnittstellen hat man zumindest bei Win ja schon, afaik kann ich auch als Treiber nicht einfach Interne Funktionen aufrufen - auch oder gerade weil die Parameter unbekannt sein dürften...

__________________

"It is the human race! The deterioration of the spirit of man. Man undermining himself, causing a self-willed, self-imposed, self-evident self-destruction."

+++ BREAKING +++ Troll ertrinkt im Planschbecken +++