Thema: Kerneldesignfrage

[matheguru]

Ich wollte fragen ob der Aufbau meines Kernel richtig ist?
Mein Kernel soll ein Mikrokernel mit einem monolithischen Teil werden:
Monolith:
 - Physische speicherverwaltung
 - Virtuelle speicherverwaltung
 - SATA/ATA treiber
 - fat32 foramt lesen (um die einzelnen Module des kernels zu laden)
 - elf format lesen
Ist das soweit richtig? was ist überflüssig? was fehlt ?
Was muss dann in den Mikroteil rein?
Und was gehört dann in die Treiber?

grüße Paul

[chris12]

ich würd sagen alles andere, wie zB
-video treiber
-floppy (vllt gleich in den mon teil)
-keyboard treiber
-etc

[jgraef]

Ich wollte fragen ob der Aufbau meines Kernel richtig ist?
Mein Kernel soll ein Mikrokernel mit einem monolithischen Teil:
Monolith:
 - Physische speicherverwaltung
 - Virtuelle speicherverwaltung
 - SATA/ATA treiber
 - fat32 foramt lesen (um die einzelnen Module des kernels zu laden)
 - elf format lesen
Ist das soweit richtig was ist überflüssig was fehlt ?
Was muss dann in den Mikroteil rein?

grüße Paul

Es gibt keinen Microkernel mit monolithischen Teil. Entweder Microkernel oder Monolith. In deinem Fall ist das wohl eher ein Monolith. Du könntest den ATA- und FAT32-Treiber auch in eigene Module machen. Laden kann die dir Grub.

[chris12]

ist das was er will nicht eher ein hybrit kernel?

[kevin]

Auf jeden Fall fehlt Prozeßverwaltung/Multitasking und wenn noch Mikrokernelaspekte reinsollen, brauchst du vermutlich auch irgendeine Form von IPC.

[matheguru]

Also floppy werde ich eh nicht unterstützen! Brauch man Prozessverwaltung um die Mikrokernelmodule zu laden und ausführen zu lassen? Keyboardtreiber gehört doch nciht unbedingt in den Kernel oder nicht ? Naja ich muss ja eine art hybrid machen, da ich ja grub etc. nicht benutzen möchte und mein eigener bootloader nur eine Binärdatei aus der ClusterKette lädt.

[bluecode]

Brauch man Prozessverwaltung um die Mikrokernelmodule zu laden und ausführen zu lassen?

Ja.

Keyboardtreiber gehört doch nciht unbedingt in den Kernel oder nicht ?

Nein, braucht man nicht.

Naja ich muss ja eine art hybrid machen, da ich ja grub etc. nicht benutzen möchte und mein eigener bootloader nur eine Binärdatei aus der ClusterKette lädt.

Dann ist eventuell dein Bootloader "zu dumm" für dein Projekt. Wir raten ja sowieso zu Grub (auch wenn wir jedes Mal aufs neue gegen Wände sprechen)...

[matheguru]

Ok kann schon sein aber wie schon im anderen Thread erwähnt ich möchte GRUB nicht. Na ja ich habe mich kurzerhand entschlossen doch ein Monolith zu machen und die Kommunikation der Komponenten werde ich irg. über nachrichten gestalten.

[bluecode]

Na ja ich habe mich kurzerhand entschlossen doch ein Monolith zu machen und die Kommunikation der Komponenten werde ich irg. über nachrichten gestalten.

Dann hast du irgendwas nicht verstanden. Bei einem Monolith geschieht die Kommunikation über direkte Funktionsaufrufe. Bei einem Microkernel über Nachrichten oä. (aka IPC = Interprozesskommunikation).

[matheguru]

Da habe ich mich misständlich ausgedrückt, ich meinte die Kommunikationen zu den Treibern wie Keyboard,Graka, etc. mache ich dann irg. über Nachrichten.

[bluecode]

Exakt so habe ich dich verstanden. Aber bei einem Monolith sind diese ja im Kernel. Also wird eben nicht über IPC, sondern direkt über Funktionsaufrufe kommuniziert.

Es könnte natürlich sein, dass du eigentlich Microkernel meintest, als du Monolith gesagt hast 

[matheguru]

Wenn du das so sagst, dann were ich froh wenn du mir noch mal den genauen, beachte auf genau, aufbau von einem mikro- u. monolithischenkernel. vieleicht kannst ja auch erwähnen was alles rein gehört auch treibertechnisch wie dateisystem, hd-treiber, tastaturtreiber, etc.
danke

[kevin]

Ich nehme mal stark an, bei diesem Konzept kommt am Ende weder ein Monolith noch ein Mikrokernel raus, sondern irgendeine komische Art von Hybrid.

Auf GRUB verzichten kann man, wenn man es unbedingt will. Aber die Entscheidung, auf einen vernünftigen Bootloader komplett zu verzichten und dafür die Möglichkeit eines sauberen Kerneldesigns zu opfern, weil er das ganze Zeug miterledigen können muß, das eigentlich ein Bootloader machen sollte - das ist für mich schwer nachvollziehbar.

Wobei ich natürlich einsehe, daß ein vernünftiger Bootloader viel Arbeit ist. Deswegen nimmt man ja normal auch GRUB.

[bluecode]

Mikrokernel (zu den einzelnen Punkten steht was unserem Wiki ) enthält:
* Speicherverwaltung
* Prozessverwaltung
* Interprozesskommunikation (IPC)

monolithischer Kernel enthält:
* alles obere auch
* alle Treiber

Bei einem Mikrokernel werden die Treiber hingegen in eigene Prozesse, d.h. in schedulbare Einheiten die (auf x86/x64 Prozessoren) in Ring 3 laufen. Bei einem monolithischen Kernel sind die Treiber entweder statisch in die Kernelbinary gelinkt (also einfach der Kernel und alle Treiber kompiliert und alles zusammengelinkt in eine Binary) oder die Treiber werden dynamisch dem Kernelimage hinzugefügt. Bei beiden Varianten laufen die Treiber (auf x86/x64 Prozessoren) in Ring 0.

Das wäre jetzt die scharfe Trennung von Mikrokernel und monolithischem Kernel. Aber man kann jetzt natürlich beliebige Zwischenstufen auch wählen.

[matheguru]

Aber wenn alle Treiber im Kernel drinn sind bei einem Monolithen, dann muss es ja auch eine implementation geben um die gerätespezifischen Treiber der Firmen irg. hinein zu bekommen, oder wie? Bei Windows sind die nämlich in einem eigenem Ordner und nicht im Kernel, oder nicht?

[kevin]

"Im Kernel" heißt nicht unbedingt, daß am Ende alles in einer einzigen Datei liegt. Es heißt nur, daß die Treiber volle Kernelrechte haben (also Ring 0) und im selben Adreßraum laufen. Ladbare Kernelmodule kann man natürlich trotzdem machen - siehe Linux (von Win habe ich nicht viel Ahnung).

[matheguru]

Na ja wenn das so ist, stelle ich mal an dieser Stelle eine andere Frage! Was ist denn mit der Sicherheit, wenn Treiber auch die vollen Rechte erhalten, wie der Kernel. Das ist ja wiederrum eine Systemschwäche, die zum absturtzt führen kann und evtl. hackern erlaubt mithilfe von eigene Treibern Schaden zuzuführen. Ist nicht dann doch sinnvoll einen Mikrokernel zu machen wo die Treiber dann im Ring 3 laufen?

[bluecode]

Was ist denn mit der Sicherheit, wenn Treiber auch die vollen Rechte erhalten, wie der Kernel. Das ist ja wiederrum eine Systemschwäche, die zum absturtzt führen kann und evtl. hackern erlaubt mithilfe von eigene Treibern Schaden zuzuführen.

Das ist eine Systemschwäche, wenn
1. Der Benutzer der den Treiber laden möchte so etwas überhaupt darf und
2. Der Treiber überhaupt geladen werden kann
Man kann bei beidem ansetzen:
1. Bestimmten Benutzern die Rechte dafür entziehen
2. Nur (von dir/deiner Firma) signierte Treiber erlauben (Das wäre dann eine Whitelist) oder einen "Virenscanner" für Treiber (Blacklist)
In der Praxis gibts sowohl das mit den Benutzerrechten (Linux und neuere Windows) als auch Whitelisting (Neuerere Windows). Alternativ kann man natürlich das Problem ignorieren (ältere Windows, die meisten Hobby-OS).

Ist nicht dann doch sinnvoll einen Mikrokernel zu machen wo die Treiber dann im Ring 3 laufen?

Trotz allem musst du Treibern spezielle Operationen erlauben, da sie spezielle Speicherbereiche, I/O-Bereiche und Interrupts benötigen. Insofern bekommst du auch Sicherheitsprobleme, wenn auch m.E. geringere.

[matheguru]

Ja aber die Treiber können im Ring 3 laufen, wenn sie nur über syscalls mit dem Kernel kommonizieren, aber ich merke schon die performence ist besser wenn sie im Ring 0 laufen und es ist auch einfacher sie zu implementieren, wenn man nicht ständig auf syscalls zugreifen möchte.

[kevin]

Der Punkt ist, daß du auch in Ring 3 keine vollkommene Sicherheit hast. Treiber brauchen Hardwarezugriff und Hardware ist außerhalb des Kernels und damit tendenziell böse. Konkretes Beispiel: Die meisten Treiber brauchen irgendeine Form von DMA und für das gelten keine Zugriffsbeschränkungen. Sobald der Treiber also an die Hardware rankommt und DMA machen kann, kann er auch den Kernel überschreiben.