Microkernel vs monolithischer Kernel

Microkernel vs Monolithischer Kernel

  • Microkernel ist besser

    Abstimmungen: 22 75,9%
  • Monolithischer Kernel

    Abstimmungen: 2 6,9%
  • Was sind`n das für Dinger? Kann man das essen :-)?

    Abstimmungen: 5 17,2%

  • Anzahl der Umfrageteilnehmer
    29
Hallo an alle (vor Allem an die Unix-Nutzer):D,
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;)
 
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.
 
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!
 
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 :D Für den PC ist das Konzept auf jedenfall deutlich besser geeignet als ein monolithischer :)
 
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)?
 
Klar würde es mir Spass machen, sonst hätte ich wahrscheinlich gar nicht nach eurer Meinung gefragt :D
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.
 
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 :rolleyes:. 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:
wikipedia hat gesagt.:
Im Jahre 2009 wurde am Forschungsinstitut NICTA in Zusammenarbeit mit der UNSW mit seL4 erstmals ein für allgemeine Anwendungen tauglicher Betriebssystemkern formal verifiziert, d.h. es wurde mathematisch bewiesen, dass die Implementierung die Spezifikation des Kerns erfüllt und somit funktional korrekt ist. Dies bedeutet unter anderem, dass der Kern nachweislich keinen der bisher verbreiteten Entwurfsfehler (Speicherüberläufe (Buffer Overflow), Zeigerfehler und Speicherlecks) enthält.
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.os.minix/browse_thread/thread/c25870d7a41696d2/f447530d082cd95d
 
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 ;)
 
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 ;)
 
Formal bewiesene Systeme bringt keine zusätzliche Sicherheit.
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.

Compiler arbeitet korrekt oder das die Hardware korrekt funktioniert.
Bei Hardware lässt sich eher nichts machen, aber ein Stichwort zum Compiler wäre Ada & Compilervalidierung (*denkt gerade an "gcc -O3" *:rolleyes: )

Und allgemein denke ich bei Micorkerneln nicht nur an "anit-rooting" Sicherheit, sondern auch an ganz normale Systemstabilität ;)
 
Allgmein hält sich der Kernelcode doch sehr in Grenzen, was das auditen ziemlich erleichtern sollte.

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.
 
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
 
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...
 
Im Jahre 2011 sollten wir eigentlich wissen: Besonders diese Frage ist perspektivisch zu betrachten.

Denn, geht es um eine NEUENTWICKLUNG eines Systems, so spricht sicherlich vieles eher für eine Microkernelarchitektur im Hinblick, wenn sie denn auf einer Serverlandschaft laufen soll. Der Gedanke meine Festplattentreiber in eine "cloud" auszulagern, waehrend der Tastaturpoller auf meinem Laptop rennt, klingt zwar schwachsinnig, aber irgendwie auch reizvoll.

Schreibe ich realtime systeme in der Industrie, die auf ARMs rennen soll, so bin ich doch mit einem monolithischen Kern besser beraten. Besonders wenn der Funktionsumfang eher gering ist.


Was bestehende Systeme angeht, so steht das praktikable im Vordergrund.
Kann ich einen BSD Kern umbauen?
Kann MS den NT Kern umbauen?
Wird HURD Fertig?

Bei Linux erübrigt sich die Frage, denn das Zeug gehört eh auf den Mist.
 
Zurück
Oben