Thema: VertaOS Neuanfang

[475]

Hi,
ich habe vor ca 1-2 jahren mal ein os angefangen VertaOS was ich allerdings aus Zeitgründen einstellen musste. Nun wollte ich wieder anfangen und habe gravierende Fehler im Design festgestellt, so dass es besser währe nochmal neu anzufangen.

Den Aufbau hab ich mir folgend gedacht:

Bootloader FAT12 lädt kernel im RM
Der Kernel switcht in den PM nachdem er die nötigen Treiber geladen hat

Im Kernel enthalten sind folgende Funktionen:

Code: [Auswählen]

Protectedmode (GDT, TSS etc)
Interrupts (IDT, PIC etc)
Memorymanager
Video Treiber (Nur für Kernelmeldungen)
Module (PL0):
Taskmanager
VFS
FDD/HDD
... (kommt später)

Treiber-Tasks (PL2):
Usermanager (Als System, kann nicht beendet werden und wird versteckt

Da der Usermanager als Task läuft, kann er den Kernel nicht direkt beeinflussen und greift nur über eine API auf den Kernel zu.

Normale tasks und Anwendungen laufen auf PL3

Der ganze Rest wird dann Nachgeladen.
Entweder als Modul oder als Task (beides soll möglich sein).
Die Treiber können untereinander Kommunizieren über "Briefkästen", also ein Treiber schickt eine Anfrage/Befehl an einen anderen. Dieser wiederum kann ihn dann annehmen und antworten oder auch ablehnen, muss hier aber eine Nachricht an den Kernel schicken. Sollte der Befehl abgelehnt  und keine Nachricht an den Kernel geschickt werden, wird es als Nichtausführung der Aufgabe gewertet und der Treiber wird als defekt angesehen und wieder entladen (unload - weiß kein vergleichbahr deutsches wort).

Das Paging etc will ich etwas abändern, so dass ich eine art "Dateisystem" im Ram habe. Das hat den vorteil, dass wenn ein Fehler auftreten sollte das Debuggen um etliches erleichtert wird (als Zusatzfunktion).

Die Geräte werden wie bei Linux über DevFS angesprochen.

Es wird die möglichkeit geben, dass ein Programm eine Anfrage an den Kernel schickt (ev. mit bestätigung des users), damit die Anwendung dann z.B. direkt auf die Grafikkarte zugreifen kann ohne auf die verhälltnissmäßig langsame API zurückzugreifen.

Für kompatibilität werde ich mich so gut ich kann an den POSIX standard (IEEE Std 1003.1) halten.

Die Ordnerstruktur werde ich an FHS anlehnen (nur anlehnen ^^):

Code: [Auswählen]

/ Hauptverzeichnis
/bin Programme (Nur Verzeichnis)
  |- /sys Systemprogramme
  |- /programm Programme installieren in separate Ordner
/boot Bootloader
/doc Dokumentationen (Nur Verzeichnis)
  |- /sys Dokumentationen über das System
  |- /programm Dokumentationen über ein Programm
/etc Konfigurationen (Nur Verzeichnis)
  |- /sys Systemkonfigurationsdateien
  |- /programm Konfigurationen der einzelnen Programme
/home       Heimatsverzeichnis (Nur Verzeichnis)
  |- /benutzer Heimatsverzeichnis eines Benutzers
  |- /root Heimatsverzeichnis des Administrators
/lib Bibliotheken (Nur Verzeichnis)
  |- /lib-name Bibliotheken liegen in separaten Ordnern
/sbin Programme für Admin (Nur Verzeichnis)
  |- /programm Programme die vom Administrator ausgeführt werden können
/tmp Temporärer Ordner


Was haltet ihr davon und habt Ihr Vorschläge, was man besser machen könnte? (es soll aber realisierbahr bleiben ^^)

[bluecode]

Ich würd auch FDD/HDD & Fat12 Treiber aus dem Kernel in ein Modul auslagern, damit du nicht dann auch noch das CDROM-Dateisystem und Treiber für ATAPI und andere Bootmedien im Kernel implementieren musst, sondern bequem als Modul (vllt. dann über grub, tip von mir ) laden kannst.

[475]

Kurz:

Im Kernel:
Speicherverwaltung
Modulverwaltung
Taskmanager

Den Rest als Module / Tasks

FAT12 werde ich vorraussichtlich als aufsatz nehmen (VFS). Damit tu ich mich später leichter beim hinzufügen weiterer Dateisysteme

Wo auch eine Frage währe:
Wo binde ich am besten die Userverwaltung ein? Kernel oder als Modul oder Task.
Nachteil kernel: Ich will so wenig wie möglich drin haben, dass weniger Fehlerquellen drin sind (stabilität)
Nachteil Modul: Leichteres Ziel für Cracker (sicherheit)
Nachteil Task: Siehe Modul

Nachtrag:
Als Verzeichnisstuktur werde ich mich weitgehend an FHS halten, da dieses System mir sehr gut gefällt. (http://www.pathname.com/fhs/pub/fhs-2.3.html)

[FreakyPenguin]

Also ich hätte die Benutzerverwaltung keines Falls im Kernel implementiert. Das würde später auch das einbinden andere Bentuzerdatenbanken zu verwenden(zB auf einem Server).

Warum sollte denn die verwendung eines Moduls ein leichteres Ziel für Cracker darstellen?
Sofern du mit Paging arbeitest, was du sehr wahrscheinlich tun wirst, sehen die einzelnen Module von einander eh nichts.

[JensFZ]

Du hast zwar recht mit den Paging und nichts voneinander sehen aber wenn du ein manipuliertes modul lädst, kannst du über gates zugriff auf den kernel erhalten und somit schadhaften code ausführen. also im schlimsten fall ganz gekonnt am paging vorbei navigieren. somit könnte man vollzugriff auf das system erlangen.

[475]

Danke JensFZ, das war auch mein Gedanke ^^

aber wo bringe ich es am besten unter (userverwaltung)?
und was haltet ihr allgemein vom aufbau (alles)?

[nooooooooos]

Du hast zwar recht mit den Paging und nichts voneinander sehen aber wenn du ein manipuliertes modul lädst, kannst du über gates zugriff auf den kernel erhalten und somit schadhaften code ausführen. also im schlimsten fall ganz gekonnt am paging vorbei navigieren. somit könnte man vollzugriff auf das system erlangen.

Naja...wenn ein Cracker in den Kernel kommt, ist es sowiso egal ob die Userverwaltung im Kernel oder in einem Modul ist^^

Gruss
Noooooooooos

[JensFZ]

Es geht ja nicht darum, dass ein Cracker da rein kommt. es geht darum wie leicht man rein kommen kann. und mit einen Modul ist das leichter als wenn man das halbe System auf den Kopfstellen muss.
wenn z.B. das Modul im Ring 0 oder 1 steht, ist es schon leichter als wenn man über eine Software kommt, die im Ring 3 arbeitet. Aber ich glaube wir kommen vom Thema ab.

[475]

Mir ist wohl bewusst, wenn jemand in den Kernel kommt, dass da quasi alles zu spät ist, aber ich will es eben von vornherein einigermaßen sicher machen.

Aber wie mein Vorredner schon gesagt hat...
Was haltet ihr vom Design?
Ich habe den Text oben angepasst, sodass die änderungen aufgrund der Posts hier oben mit eingeflossen sind.

Danke schonmal ^^

[nooooooooos]

Nicht schlecht, aber Taskverwaltung und Videotreiber würde ich auch aus dem Kernel rausnehemen...

(Und solange du noch nicht soweit bist, dass der Videotreiber funktioniert, kannst du vom Kernel einfach per mov BYTE [0xb8000],'s' ein Zeichen ausgeben...)


Gruss
Nooooooooooooooos

[475]

Taskverwaltung brauch ich für (manche) Treiber und ob ich die gleich im Kernel habe oder später als Kernelmodul lade (ich MUSS ihn ja sehr früh laden) dürfte eigendlich egal sein.

Der Videotreiber im Kernel ist nur für einfache Textausgabe (wenn der Kernel z.B. fehler beim laden des echten Videotreibers hat, kann er was rausschreiben).

[nooooooooos]

Jojo...aber du könntest den tasktreiber auch als modul gebrauchen um andere Treiber zu laden^^

[475]

Das währ auch ne möglichkeit