Thema: was gehört in einen kernel?

[kleiner]

Also prinzipiell muss man natürlich um Module umsetzen zu können, erstmal ELF oder des von Microsoft umsetzen, sonst ist nicht viel mit Modulen.
Übersichtlich kann man den monolithischen Kernel schon gestalten, das stimmt schon.
Du darfst nicht direkt von einer Umsetzung aufs ganze Konzept schließen. Microsoft verwendete auch lange die RC4-Verschlüsslung und sah die als sicher an, aber man kann die ganz leicht knacken. Ist deswegen Kryptographi gleich schlecht?
Und warum sollten nicht alle Treiber Root-Rechte haben. Ganz einfach, weil das mehr Möglichkeiten bietet, unerlaubt durch Programmierfehler an Root-Rechte zu kommen. Und wofür soll ein Treiber, der nicht anderes macht als z.B. Signale an ein paar LEDs zu leiten Zugriff auf die Speichertabellen oder die tiefsten Kernelfunktionen haben. Das schafft nur die Möglichkeit für Sicherheitslücken und die gibt es meist schon genug.

[chr15]

@Teejay: ja, das ist der Unterschied zwischen mir und den anderen Menschen: Wenn ein System abstürtz, dann bei mir; wenn es ein fehler gibt, dann tritt er bei mir auf.
Aber lass uns nicht streiten, jeder macht das, was er für besser hält (Hängt ja auch immer von dem Fall ab; was man proggen will...)
@kleiner: Was soll den das jetzt mir RC4?(ist sowieso nicht so gut wie mein Algorithmus; Aber den muss ich erst noch weiter überprüfen ) Ich habe doch garnicht behauptet, das Verschlüsselung schlecht ist. worauf beziehst du das jetzt??? Aber bei dem Microkernel haben die Programme ja auch alle (wenn auch indirekt) vollen zugriff auf die Hardware, sonst könnten die Treiber ja auch nicht die Hardware treiben...

[kleiner]

Das Beispiel mit der Veschlüsselung war ein Vergleich, weil Du von der Instabilität eines Redmonder MIcro-Kernel-Systems auf alle Micro-Kernels geschlossen hast. Ich wollte damit zeigen, dass jene Firma nicht unbedingt herangezogen werden sollte, wenn es um Rückschlüsse auf die jeweils zugrunde liegende Philosophie geht, wie hier eben Micro-Kernel und Verschlüsselung.
Ja, klar die einzelnen Treiber haben Zugriff auf die Hardware, das stimmt schon, aber es geht um Rechteverteilung: In einem Monolith hat jeder Treiber volle Kernelrechte, weil es sich ja um ein Programm handelt. Wenn Du nun einen einfachen FS-Treiber bastelst und dort einen Programmierfehler reinbaust, der etwas schwerwiegender ist, wirst Du damit die Möglichkeit bieten, volle Root-Rechte zu bekommen.
Wenn Du dagegen einfach einem Server diese Arbeit überlässt, der dann nicht als Root laufen muss, wird ein solcher Fehler nicht dazu führen, dass der Angreifer Root-Rechte erhält. Und ein FS-Server braucht keinerlei Zugriff auf die Graphikkarte oder die Eingabe. Für den FS-Server reicht Zugriffsrechte auf die Festplattenserver, um die Daten auslesen zu können.

[Another Stupid Coder]

kleiner postete
[...]... unerlaubt durch Programmierfehler an Root-Rechte zu kommen. [...]

<--- Siehe Buffer-Overflow ... Man sollte zumindest davon absehen GUI und Console (root-konsole bildet eine Ausnahme) in den Kernel zu integrieren.

[chr15]

@Kleiner: Ich habe nie behauptet, dass ein Monilithischer Kernel stabieler ist als ein Microkernel!!!!! Ich habe nur gesagt, das es auch nicht abders herum sein muss!!!!!!!!!
Wegen der Sicherheit: Gleiches Beispiel!
Meiner Meinung nach haben beide Systeme Vorteile und Nachteile. Man sollte am besten etwas gemischtes nehmen! (Und in dem Maße, dass man die Vorteile von beiden hat, aber nicht die nachteile!)

[Roshl]

Wenn das ganze so einfach wäre hätten wir schon lange das perfekte Betriebssystem;)

[mastermesh]

Wollte nur kurz anmerken, dass es sehr viel schwieriger ist, ein gut durchdachtes Micro-Kernel-System zu entwerfen, also ein einfaches monolithisches System zu entwerfen. Der Grund ist vor allem die Kommunikation zwischen den Servern/Treibern. Benutzt man Ports? Pipes? Messages? Lässt man alles über ein virtuelles Netzwerk laufen, damit man später eventuell Anwendungen über LAN starten kann?

Ihr seht schon, die Theorie ist einfach, aber Microkernels sind kompliziert...

[Another Stupid Coder]

Ja, schon aber da ein Betriebsystem sowieso schon kompliziert ist und es genug gute Beispiele für einen Microkernel gibt (siehe spoon) finde ich das sich die arbeit auszahlt.

[kleiner]

Tja eine interessante Anwendung für einen Micro-, wenn nicht gar Exo-Kernel, wäre sicher Clustering oder gar Griding. Wenn man wirklich alles, bis auf die Ausführung auf Server verteilt und die über Sockets kommunizieren lässt, könnte man vielleicht sogar ein komplettes Netzwerk mit einer OS-Instanz betreiben. Das würde natürlich vorraussetzen, dass auch der Scheduler, oder wenigstens ein Hauptscheduler, als Server implementiert ist. Das wäre dann wirklich ein delokalisiertes OS.

[chr15]

Schon mal was von Mosix gehört? Clustering ist auch mit einem monolithischen Kernel kein Problem!

[kleiner]

Klar ist Clustering auch mit Monolithen kein Problem. Linux lässt sich auch gut clustern, aber meine Idee würde halt einen einzigen "PC" auf x Rechner verteilen, wobei die Performance, sehr gutes Netzwerk vorrausgesetzt, durch die verteilung der Server für gro skalierende Netzwerke steigen würde.

[lobmann]

Ein OS über Sockets klingt interessant gibts sowas schon Ansatzweise irgendwo im Netz??

[chr15]

@kleiner: Was ist denn Mosix. Das kann man auch bedienen, wie EINEN PC. Also keine wirklich neue Erfindung

[kleiner]

Ok, kenn Mosix nicht.
OK, aber selber erdacht.
Wenigstens etwas.

[WilhelmHH]

Sicher das BSD ein Microkernel ist? ich hatte es nur ca. 2 Tage installiert aber es kahm mir so...monolithisch vor...

Dazu  http://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/kernelconfig-custom-kernel.html
"Traditionell besaß FreeBSD einen monolithischen Kernel."

[FreakyPenguin]

Was soll es denn bringen, die alten Threads von 2004 aus der Versenkung hervor zu holen?

[ChristianF]

Tjaja und nochmal das Thema aufwärmen... 
 
Ich möchte einen Mikrokernel schreiben.
Folgendes habe ich aufgeschrieben, was in den Kernel soll:

Code: [Auswählen]

# Multiboot kompatibler 32-Bit Protected Mode Kernel
## GDT
## IDT
## ISRs
## IRQs and the PICs
## PIT (Programmable Interval Timer)
# Einfacher Video-Treiber zur Textausgabe (vllt. auch nicht)
# Memory Manager
# Multitasking
# System Calls
# Interprozesskommunikation
# Modul Interface
# Prozessorspezifischer Kram
## FPU-Support
# Treiberinterface
Aber irgendwie denke ich die ganze Zeit, dass da doch irgendwas fehlt oder nicht?
 
Gruß Christian

[kevin]

Ich nehme das "oder nicht". Einige Begriffe da drin sind so breit gefaßt (z.B. "System Calls"), daß du damit eigentlich alles abdeckst. Ansonsten: Wenn du das alles abgearbeitet hast, hast du sicher mehr Gefühl für die Sache und weißt, was als nächstes kommen muß. Für einen Mikrokernel wird sich das aber höchstwahrscheinlich im Userspace abspielen.

[ChristianF]

Gut das war alles was ich wissen wollte.
Danke.
 
Gruß Christian

[ChristianF]

Und nocheinmal eine Frage, da ich ja keinen neuen Thread deswegen aufmachen will.
 
Wie habt ihr Prozessorspezifische Features, wie z.B. PAE, implementiert? Die Idee, die mir kam, war eine Art "Systemtreiber", der abhängig von der CPU kompiliert wird und in der initrd liegt. Ist das sinnvoll?
Ich würde dann nämlich als minimale Vorgabe einen i386 kompatiblen Prozessor angeben, und wenn man irgendwas spezielles haben will (PAE), wird das über den Systemtreiber gemacht.
 
Der Nachteil an der Geschichte ist halt, dass man diesen nicht mitliefern kann, sondern vor Ort kompilieren und linken muss.
Ich möchte halt nicht zig verschiedene Versionen von meinem Kernel. Ich würde gerne "nur" unterscheiden zwischen z.B. Intel und AMD...
 
Beispiel: Pentium 1 unterstützt ja bekanntlich kein PAE, dafür aber der Pentium Pro. Und damit der Kernel nicht vollmüllt (meine Ansicht), kann der Nutzer mit dem Pentium Pro sich dann diesen Systemtreiber bauen. Oder man baut dies während der Installation, falls ich irgendwann mal soweit kommen sollte *träum*.
 
Das ganze ist begrenzt auf 32Bit. Es gibt ja nicht die Möglichkeit, einen Kernel zu bauen, der 32Bit und 64Bit in einem vereint...