Thema: Treiber "Management"

[FlashBurn]

Ich mache mir gerade Gedanken darüber wie man Treiber performant "managen" kann.

Damit meine ich, das z.B. nicht jeder Treiber geladen und ausgeführt wird und dann guckt ob ein Gerät, das er unterstützt, vorhanden ist, sondern das ein Treiber auch immer nur dann ausgeführt wird, wenn ein Gerät für ihn vorhanden ist.

Ich hatte mir da folgendes überlegt. Ich könnte als Anforderung für einen Treiber sagen, dass dieser eine bestimmte ELF-Sektion haben muss, wo in einer genau definierten Datenstruktur die Geräte drin stehen, die er unterstützt.
Problem wäre hier, das ich das ganze dann für jedes Bussystem (ISA, PCI, USB, ...) extra machen müsste.
Vorgestellt habe ich mir das so, dass der Device-Server das Verzeichnis wo die ganzen Treiber drin sind "beobachtet" (also benachrichtigt wird, wenn eine Änderung aufgetreten ist) und dann alle Dateien in dem Verzeichnis "parst" (also den ELF-Header laden und die spezielle Sektion, wo die Daten drin sind) und sich eine Liste anlegt.

Soweit so gut. Wie könnte man es machen, das die Liste nicht bei jeder Änderung neu erstellt wird? Ich dachte, das man vielleicht neben dem Dateinamen, noch die Zeit der letzten Änderung speichert. Damit kann ein Treiber gegebenenfalls neugeladen werden, wenn eine neuere Version in das Verzeichnis kopiert wurde.

Was haltet ihr davon, was würdet ihr anders/besser machen?

[Svenska]

Du könntest eine sortierte statische Liste machen, in der alle unterstützten Hersteller-/Gerätenummern aufgeführt sind und darin suchen, wenn du ein Gerät findest. So eine Art Datenbank.

Statisch, weil du diese nur aktualisieren musst, wenn ein Treiber aktualisiert wurde und nun neue/zusätzliche IDs unterstützt oder ein neuer Treiber da ist.

Die Liste kannst du semi-manuell aktualisieren, wenn du einen neuen Treiber einspielst (sowas wie "depmod -a") oder du schaust einfach nach Datum/Uhrzeit im Dateisystem, d.h. ob die Liste neuer ist als alle Treiber oder nicht. Das dürfte wesentlich schneller sein, als jeden Treiber erstmal zu öffnen und dann festzustellen, dass er total sinnlos auf diesem System ist.

Treiber neu laden würde ich jedenfalls nie automatisch machen; sonst kann jemand einen Server zum Absturz bringen, indem er Schreibzugriff auf das Treiberverzeichnis erlangt. Ungünstig.

Für PCI/USB kannst du ja vom Devicemapper (der die Bussysteme verwaltet) die Treiber laden lassen, ISA wäre manuell relativ sinnvoll (eine feste Liste zu ladender Treiber), da man ISA-Geräte nur proben kann.

Gruß,
Sebastian

[FlashBurn]

Du könntest eine sortierte statische Liste machen, in der alle unterstützten Hersteller-/Gerätenummern aufgeführt sind und darin suchen, wenn du ein Gerät findest. So eine Art Datenbank.

Das ist nicht ganz das was ich erreichen will. Die Frage ist dann wann wird diese Datenbank erstellt und wo bekommt sie wie ihre Daten her?

Statisch, weil du diese nur aktualisieren musst, wenn ein Treiber aktualisiert wurde und nun neue/zusätzliche IDs unterstützt oder ein neuer Treiber da ist.

Da triffst du schon eher das was ich erreichen will. Diese Datenbank sollte jedes Mal aktualisiert werden, wenn eine Veränderung im Treiberverzeichnis (löschen/neu/geändert) stattgefunden hat.

Das dürfte wesentlich schneller sein, als jeden Treiber erstmal zu öffnen und dann festzustellen, dass er total sinnlos auf diesem System ist.

Wo wir wieder bei der Frage wäre, wo bekommt die Datenbank die Daten her? Ich muss die Datei öffnen um zu wissen welche Geräte der Treiber unterstützt.
Steht die Datei schon in der Datenbank, würde ich aufs letzte Änderungsdatum gucken und schauen ob der Treiber eventuell neuer ist als der der in der Datenbank eingetragen wurde.

Treiber neu laden würde ich jedenfalls nie automatisch machen; sonst kann jemand einen Server zum Absturz bringen, indem er Schreibzugriff auf das Treiberverzeichnis erlangt.

Aber genau das möchte ich (nicht den Absturz ). Ein Treiberupdate wäre dann einfach, neuen Treiber über alten Treiber kopieren und dem alten Treiber signalisieren das er "runtergefahren" wird und neuen Treiber laden.
Genauso einfach sind dann Installation/Deinstallation, einfach in das Verzeichnis kopieren bzw. einfach daraus löschen/verschieben.

Wie genau stellst du dir das vor, dass ein Server abstürzt, weil jemand Schreibzugriff auf das Treiberverzeichnis bekommen hat?

Für PCI/USB kannst du ja vom Devicemapper (der die Bussysteme verwaltet) die Treiber laden lassen, ISA wäre manuell relativ sinnvoll (eine feste Liste zu ladender Treiber), da man ISA-Geräte nur proben kann.

Wollte ich genauso machen, sprich der Busmanager (außer ISA) hat ne Liste mit Geräten die im System vorhanden sind und dann wird in der Datenbank nachgeguckt ob ein Treiber vorhanden ist (falls ja -> wird dieser geladen) und wenn der Treiber geladen ist, muss dieses Gerät in eine Liste "Geräte mit laufenden Treiber" gepackt werden.

Ziel ist es vorallem meinen Bootvorgang (für mich) zu vereinfachen und die Installation/Deinstallation/Update zu vereinfachen.

[Svenska]

Du könntest eine sortierte statische Liste machen, in der alle unterstützten Hersteller-/Gerätenummern aufgeführt sind und darin suchen, wenn du ein Gerät findest. So eine Art Datenbank.

Das ist nicht ganz das was ich erreichen will. Die Frage ist dann wann wird diese Datenbank erstellt und wo bekommt sie wie ihre Daten her?

Naja, du schaust beim Systemstart nach, ob die Liste existiert. Wenn nein, erzeugst du sie. Wenn ja, schaust du nach, ob eine Treiberdatei neuer ist als deine Liste (damit sparst du dir, die Dateien zu öffnen).  Ist deine Liste veraltet, erzeugst du eine neue.

Statisch, weil du diese nur aktualisieren musst, wenn ein Treiber aktualisiert wurde und nun neue/zusätzliche IDs unterstützt oder ein neuer Treiber da ist.

Da triffst du schon eher das was ich erreichen will. Diese Datenbank sollte jedes Mal aktualisiert werden, wenn eine Veränderung im Treiberverzeichnis (löschen/neu/geändert) stattgefunden hat.

Finde ich unelegant, weil du damit quasi einen Daemon im Hintergrund laufen hast, der ständig ein (unwahrscheinliches) Ereignis abprüft. Treiber werden normalerweise nur selten aktualisiert.

Treiber neu laden würde ich jedenfalls nie automatisch machen; sonst kann jemand einen Server zum Absturz bringen, indem er Schreibzugriff auf das Treiberverzeichnis erlangt.

Aber genau das möchte ich (nicht den Absturz ). Ein Treiberupdate wäre dann einfach, neuen Treiber über alten Treiber kopieren und dem alten Treiber signalisieren das er "runtergefahren" wird und neuen Treiber laden.
Genauso einfach sind dann Installation/Deinstallation, einfach in das Verzeichnis kopieren bzw. einfach daraus löschen/verschieben.

Betone, dass der alte Treiber (im RAM) manuell ein Signal zum "runterfahren" kriegt und wir sind uns einig.

Wie genau stellst du dir das vor, dass ein Server abstürzt, weil jemand Schreibzugriff auf das Treiberverzeichnis bekommen hat?

Betrifft den automatischen Restart von aktualisierten Treibern: Wenn dein Devicemanager neue Treiberversionen direkt automatisch startet, kannst du damit dein System zerschießen.

Wir sind uns da ziemlich einig.

Wo die Liste herkommt? Naja, wie von dir beschrieben: Ist die Liste nicht vorhanden oder veraltet, so musst du sie aus den Treiberdateien erzeugen. Es geht mir halt nur um die Masse an Neustarts, bei denen keine Treiberinstallation stattgefunden hat - da reicht die prägenerierte Liste.

Gruß,
Sebastian

[FlashBurn]

Naja, du schaust beim Systemstart nach, ob die Liste existiert. Wenn nein, erzeugst du sie. Wenn ja, schaust du nach, ob eine Treiberdatei neuer ist als deine Liste (damit sparst du dir, die Dateien zu öffnen).  Ist deine Liste veraltet, erzeugst du eine neue.

Da sind wir dann bei dem Problem mit dem Booten meines Systems, das ist leider nicht so einfach. Außerdem möchte ich einfach auch bei jedem Systemstart die Liste dynamisch erzeugen.
Der Grund dafür ist, ich lade nur die wichtigsten Treiber mit meinem Loader und nur diese tauchen am Anfang im Treiberverzeichnis auf und können genutzt werden. Würden da schon alle Treiber drin stehen, hätte ich das Problem das ich sie nicht laden kann, da der Treiber zum Laden wahrscheinlich noch gar nicht gestartet wurde.
Mit meiner dynamisch erzeugten Liste umgehe ich dieses Dilemma.

inde ich unelegant, weil du damit quasi einen Daemon im Hintergrund laufen hast, der ständig ein (unwahrscheinliches) Ereignis abprüft.

Das ist so nicht richtig. Ich will in meinen Storage-Server sowas wie nen Node-Monitor einbauen, sprich du registrierst dich als Empfänger, dass du ne Nachricht bekommen willst wenn sich ein einer bestimmten Node was ändert. Da läuft dann kein Daemon im Hintergrund, sondern das macht alles der Storage-Server.

Betone, dass der alte Treiber (im RAM) manuell ein Signal zum "runterfahren" kriegt und wir sind uns einig.

Genau, das (den Treiber runterfahren und den neuen starten) macht natürlich der Device-Server.

Betrifft den automatischen Restart von aktualisierten Treibern: Wenn dein Devicemanager neue Treiberversionen direkt automatisch startet, kannst du damit dein System zerschießen.

Das Problem würde sich dann (wenn ich das nicht machen würde) ja nur auf den nächsten Systemstart verschieben. Außerdem müsste man das dann irgendwie elegant lösen, ich meine ich möchte nicht, das ein Treiber einfach so von jedem Prozess überschrieben werden kann. Da müsste dann jedes mal was "aufleuchten", so wie das UAC

Du hast nur noch nichts zu der Idee gesagt, das ich eine spezielle Sektion in der ELF-Datei haben möchte wo drinsteht welche Geräte der Treiber unterstützt. Ich finde das so halt besser/performanter als wenn ich den Treiber erstmal starte (muss nen neuer Prozess für erzeugt werden) und ihn dann sozusagen berichten lasse.

[Svenska]

Die Idee mit der speziellen Sektion in der ELF-Datei würde ich so nicht machen, aber die Idee ist realistisch, nicht kompliziert und nachvollziehbar. Darum hab ich das nicht weiter kommentiert. Gut und so.

Zum Rest hab ich alles gesagt, was ich zu sagen hatte. Besonders die Sache mit dem automatischen(!) Treiberneustart finde ich sehr unschön, den (Re-)Ladevorgang selbst würde ich immer manuell anstoßen lassen müssen.

[kevin]

Für tyndur hatte ich mir das so gedacht, dass das Treiberpaket nicht nur die Binary mitliefert, sondern gesondert noch die Einträge für die Datenbank. Entweder als eine Datei pro Treiber (die Dateien aller Treiber landen dann in einem Verzeichnis), oder irgendein Verwaltungstool, das im Postinstallskript vom Treiber aufgerufen wird und eine komplette Datenbank hat.

[FlashBurn]

@taljeth

Was passiert, wenn ein Treiber in der Datenbank steht, aber physisch, sprich als Datei, nicht mehr vorhanden ist?

Ich würde halt die ganze Geschichte (Liste der unterstützen Geräte) gerne in der eigentlichen Treiberdatei drin haben.
Einen neuen Prozess erstellen nur am an diese Liste zu kommen ist mir zu langsam und die Liste irgendwo in der Datei zu haben (durch irgendeine Magic-Konstante markiert) ist mir auch zu aufwendig und langsam. Daher die Idee mit der extra ELF-Sektion.

Ich bin aber gerne offen für Vorschläge oder Gegenargumente.

Besonders die Sache mit dem automatischen(!) Treiberneustart finde ich sehr unschön, den (Re-)Ladevorgang selbst würde ich immer manuell anstoßen lassen müssen.

Was würdest du vorschlagen, wie man das sonst macht, weil ich da ja dann irgendeine Art Interface für haben müsste und da müsste dann auch sichergestellt werden, dass das nicht jeder machen kann.
Meine Variante ist natürlich besonders für Treiberentwickler sehr vorteilhaft.

[Svenska]

Du bräuchtest einen Syscall, der dem Devicemanager mitteilt, dass ein Treiber neu geladen/gestartet werden soll.

Alternativ, da du ja ohnehin Funktionen zum Laden und Entladen von Treibern brauchst, kannst du diese beiden Funktionen auch exportieren und dafür benutzen. Der Fall von "rmmod blubber; modprobe blubber". Diese Sequenz kannst du dann ja auch von deinen Bau-/Installationsscripten aufrufen lassen.

Die Sicherheitsregelung lässt sich über die Nutzer-ID (bei Mehrbenutzersystemen) machen. Oder, wie es die BSDs haben, über einen Security Level: Du hast eine Konstante, die du nur nach oben zählen lassen kannst (beim Booten ist sie null). Überschreitet sie einen gewissen Wert, sind bestimmte APIs deaktiviert - auch für root. Damit kann niemals (für diesen Boot) ein Programm ein Kernelmodul entladen oder etwas anderes potentiell gefährliches tun.

Deine Variante ist für Treiberentwickler vorteilhaft, aber für den Produktionseinsatz wäre es mir zu ... gefährlich. Gut, dein OS wird eher kein Produktionseinsatzsystem sein, aber ich denke halt immer an sowas.

Gruß,
Sebastian

[kevin]

Was passiert, wenn ein Treiber in der Datenbank steht, aber physisch, sprich als Datei, nicht mehr vorhanden ist?

Dann hast du von Hand am System rumgepfuscht und bist selber schuld.

Was passieren würde ist wohl, dass er versucht, den nicht vorhandenen Treiber zu starten wenn du passende Hardware hast, und dabei auf die Schnauze fliegt. Dann kannst du die Hardware eben nicht benutzen. Geht aber ohne Treiber sowieso nicht, insofern ist das eigentlich egal...

Ich würde halt die ganze Geschichte (Liste der unterstützen Geräte) gerne in der eigentlichen Treiberdatei drin haben.

Einen echten Grund dazu sehe ich nicht. Aber wenn man das unbedingt machen will, dann ist die ELF-Sektion wohl das vernünftigste.

[FlashBurn]

Du bräuchtest einen Syscall, der dem Devicemanager mitteilt, dass ein Treiber neu geladen/gestartet werden soll.

Das ist nicht böse gemeint, aber damit hast du mal wieder (für mich) bestätigt das du nur im Unix-mäßig denkst.
Ich habe einen Device-Server, dem müsste man irgendwie ne Nachricht schicken.

Alternativ, da du ja ohnehin Funktionen zum Laden und Entladen von Treibern brauchst, kannst du diese beiden Funktionen auch exportieren und dafür benutzen. Der Fall von "rmmod blubber; modprobe blubber". Diese Sequenz kannst du dann ja auch von deinen Bau-/Installationsscripten aufrufen lassen.

Ist mir wieder viel zu Unix-mäßig. Ich will Skripte soweit es geht vermeiden und schon gar nicht soll sich ein User mit einem Skript beschäftigen müssen (wenn er das will, ist das ne ganz andere Geschichte).

Deine Variante ist für Treiberentwickler vorteilhaft, aber für den Produktionseinsatz wäre es mir zu ... gefährlich. Gut, dein OS wird eher kein Produktionseinsatzsystem sein, aber ich denke halt immer an sowas.

Ich vermute mal mit Produktionseinsatz meinst du sowas wie Server und mehr geschäftlich genutzt?! Ich habe mir als "Ziel" (es sei mal dahin gestellt ob ich es jemals erreiche) gesetzt ein Consumer-OS zu schreiben, wenn man das ganze auch als Server-OS nutzen könnte ist das auch Ok, aber es ist kein Ziel.

Einen echten Grund dazu sehe ich nicht. Aber wenn man das unbedingt machen will, dann ist die ELF-Sektion wohl das vernünftigste.

Der Grund (für mich) ist die Einfachheit. Eine andere Möglichkeit wäre ein Package-System zu nutzen oder zu entwickeln, mit dem man nicht nur Programme, sondern auch Treiber installieren/deinstallieren kann.
Obwohl ich da dann wieder vor dem Problem stehe, wie ich mein OS vernünftig booten kann ohne alzu viele Ausnahmeregelungen dafür zu schaffen.

Ich werd dann also die ELF-Sektion Variante nutzen.

Noch was zum ISA-Bus, ich habe mir überlegt nur ISA-Hardware zu unterstützen die Plug&Play fähig ist, damit dürfte dann doch eigentlich das Proben entfallen oder?

[erik.vikinger]

Hallo,


Zu dem Thema des Treibermanagement hab ich mir auch mal ein paar wenige Gedanken gemacht und bin der Meinung das ich einen Driver-Loader-Service implementieren möchte der vom PCI- und USB-Basis-System benutzt wird um anhand des Class-Code oder den Vendor/Product-IDs den richtigen Treiber zu laden. Dieser Service soll eine Art primitive Datenbank benutzen in der alle Treiber drin sind. Wenn ein Treiber nicht mehr existiert oder seine Check-Summe nicht mehr stimmt dann ist es eben einfach so als wäre kein passender Treiber vorhanden. Dieser Service soll in meinem Konzept sehr früh im Boot-prozess gestartet werden und ein paar Basis-Treiber direkt enthalten (per simpler interner ROM-Disk) und erst später von INIT einen Zugriff auf ein dann gemountetes Dateisystem erhalten (und dann die interne ROM-Disk freigeben).

Automatisches Neuladen von Treibern würde ich persönlich auch als extrem riskant (oder schlimmeres) betrachten, so könnte man dem System einfach mal ein fehlerhaftes oder bösartiges Programm unterschieben das dann auch noch mit den Privilegien eines Treibers gestartet wird. Zum ändern meiner Datenbank soll auf jeden Fall eine Passwortabfrage (oder was ähnliches) gehören damit das auf keinen Fall ohne explizites Einverständnis eines berechtigten Users geschieht. Ein weiteres Problem beim automatischen Neustart sind Treiber die das Systen permanent braucht, z.B. HDD-Treiber oder Dateisystem-Treiber. QNX hat wimre ein paar Möglichkeiten gecraschte Treiber automatisch neu zu starten aber auch das ist sehr begrenzt. Zum Neustart eines Treibers gehört auch immer das die zugehörige HW deaktiviert und dann mit dem neuen Treiber reaktiviert wird und auch alle angebotenen Dienste beendet werden (also keine offenen Handles o.ä. existieren dürfen), damit bleibt nicht mehr viel HW übrig für die das möglich ist (wohl vor allem USB-Sticks usw).

Noch was zum ISA-Bus, ich habe mir überlegt nur ISA-Hardware zu unterstützen die Plug&Play fähig ist

Nenne doch mal ISA-Hardware die PnP-fähig ist. Das trifft nur ISA-HW die auf Karten verbaut ist (z.B. Soundkarten), alles was heutzutage noch an ISA-Ruinen in den Chipsätzen schlummert ist ja fest integriert und daher dem BIOS-Programmierer wohl bekannt und benötigt demzufolge auch kein PnP. Ich kann nur empfehlen ISA-HW wie PCI-HW zu behandeln die nach der Enumeration händisch (also schon anhand bestimmter Automatismen, z.B. die Zahl/Ressourcen der seriellen Schnittstellen sollte das BIOS nennen können) der PCI-Device-Liste hinzugefügt wird.


Grüße
Erik

[kevin]

Der Grund (für mich) ist die Einfachheit. Eine andere Möglichkeit wäre ein Package-System zu nutzen oder zu entwickeln, mit dem man nicht nur Programme, sondern auch Treiber installieren/deinstallieren kann.

Will man das nicht sowieso haben?

Obwohl ich da dann wieder vor dem Problem stehe, wie ich mein OS vernünftig booten kann ohne alzu viele Ausnahmeregelungen dafür zu schaffen.

Hm, inwiefern ist dein OS in dieser Hinsicht speziell? Und warum hast du dieses Problem nicht, wenn du ELF-Sektionen nimmst? Ich glaube, das musst du etwas ausführlicher beschreiben, damit ich es verstehe.

Noch was zum ISA-Bus, ich habe mir überlegt nur ISA-Hardware zu unterstützen die Plug&Play fähig ist, damit dürfte dann doch eigentlich das Proben entfallen oder?

Hm, keine Unterstützung für PIC, PIT, PS/2-Tastatur und -Maus, Floppy, ...?

[FlashBurn]

Will man das nicht sowieso haben?

Klar, aber eigentlich noch nicht jetzt, das wäre dann doch ein wenig zu viel Aufwand.

Hm, inwiefern ist dein OS in dieser Hinsicht speziell? Und warum hast du dieses Problem nicht, wenn du ELF-Sektionen nimmst? Ich glaube, das musst du etwas ausführlicher beschreiben, damit ich es verstehe.

Naja, jeder Mikrokernel der die Treiber und vorallem die Device-Verwaltung im UserSpace hat, muss sich ja irgendetwas einfallen lassen wie man vernünftig booten kann.

Problem bei mir wäre halt, das ich meinen Device-Server gerne so geschrieben hätte, das er halt nur die Treiber verwendet die auch da sind und wenn später mehr Treiber hinzu kommen (damit meine ich während der Laufzeit) dann guckt er ob er dafür nicht auch Verwendung hat.

Mit diesem Konzept vereinfacht sich das Starten dieses Servers (und von meinem OS allgemein) enorm. Denn wenn ich nur die Treiber im VFS stehen habe die auch als Modul von meinem Bootloader geladen wurden, dann versucht er auch erst gar nicht andere Treiber "nachzuladen", sondern das wird erst dann gemacht, wenn das System so weit ist, dass es Dateien von außen (HDD, USB, CD-ROM, ...) nachladen kann. Deswegen auch die dynamische Erzeugung der Liste zur Laufzeit.

Würde ich das nicht so machen, müsste ich mir was einfallen lassen um den Bootvorgang speziell zu behandeln und das könnte dann ein wenig rumgeeiere werden und das wollte ich eigentlich vermeiden.

Hm, keine Unterstützung für PIC, PIT, PS/2-Tastatur und -Maus, Floppy, ...?

Erwischt

Nein, diese "feste" Hardware wird natürlich unterstützt. Aber du hast da natürlich was sehr interessantes angesprochen. Wie findet man eigentlich raus, ob noch PS/2-Ports vorhanden sind?
Ich meine der PIC und der PIT fallen raus, weil sie in dem Sinne keine Treiber benötigen (die sind fest in meinem Kernel drin), Floppy würde ich dann so machen wie erik es schon vorgeschlagen hat (bekannte Sachen aus dem BIOS als Pseudo-PCI-Geräte in eine Liste packen) und was gibt es sonst noch?

Automatisches Neuladen von Treibern würde ich persönlich auch als extrem riskant (oder schlimmeres) betrachten, so könnte man dem System einfach mal ein fehlerhaftes oder bösartiges Programm unterschieben das dann auch noch mit den Privilegien eines Treibers gestartet wird.

Naja, wie gesagt, damit schiebt sich das Problem, des bösartigen Programms nur bis in den nächsten Bootvorgang.
Außerdem habe ich gerade keine Vorstellung welche besonderen Rechte ein Treiber gegenüber normalen Programmen hat (was natürlich jetzt nur mein OS betrifft, auf anderen OSs kann das wieder anders aussehen).
Das Problem eines fehlerhaften Treibers kannst du sowieso nicht aus der Welt schaffen (es sei denn du machst es wie MS, das nur noch signierte Treiber gestartet werden dürfen).

Ein weiteres Problem beim automatischen Neustart sind Treiber die das Systen permanent braucht, z.B. HDD-Treiber oder Dateisystem-Treiber.

Also bei sowas LowLevel wie dem HDD-Treiber seh ich da eher weniger Probleme. Wenn man sich ein vernünftiges Protokoll einfallen lässt sollte das relativ schmerzlos und schnell über die Bühne gehen. Aber auch ein VFS-Modul sollte man entladen können und das fällt bei mir auch nicht in die Kategorie Treiber, sondern wird als ne Art Add-On für den Storage-Server verwendet (ich bin da ziemlich BeOS/Haiku belastet ).
Zumal man jeden Treiber "runterfahren" können sollte und dann wird er einfach neu gestartet. Ob und wie das jetzt genau funktioniert kann ich mir immer noch Gedanken machen, wenn es dann soweit ist.

Ich hätte es nur schon gerne, das man mein OS nicht neustarten muss, nur um einen neuen Treiber zu laden bzw. einen zu updaten.

Was natürlich ausfällt ist Busmanager neu zu laden, zumal diese wiederum bei mir unter die Kategorie Add-On des Device-Servers fallen (also PCI, ISA, USB, ...).

[Svenska]

Du bräuchtest einen Syscall, der dem Devicemanager mitteilt, dass ein Treiber neu geladen/gestartet werden soll.

Das ist nicht böse gemeint, aber damit hast du mal wieder (für mich) bestätigt das du nur im Unix-mäßig denkst.
Ich habe einen Device-Server, dem müsste man irgendwie ne Nachricht schicken.

s/"einen Syscall"/"eine Nachricht"/g

Deine Variante ist für Treiberentwickler vorteilhaft, aber für den Produktionseinsatz wäre es mir zu ... gefährlich. Gut, dein OS wird eher kein Produktionseinsatzsystem sein, aber ich denke halt immer an sowas.

Ich vermute mal mit Produktionseinsatz meinst du sowas wie Server und mehr geschäftlich genutzt?! Ich habe mir als "Ziel" (es sei mal dahin gestellt ob ich es jemals erreiche) gesetzt ein Consumer-OS zu schreiben, wenn man das ganze auch als Server-OS nutzen könnte ist das auch Ok, aber es ist kein Ziel.

Das schrieb ich bereits und nahm mir die Freiheit, mich bereits vorauseilend für diese Aussage zu entschuldigen.

Minix als Mikrokernel besteht auch aus solchen Servern (MM, FS, INET). Wenn du allerdings MM beendest, kannst du ihn mangels Speicherverwaltung nicht neustarten. Beendest du FS, kannst du die Treiberdatei nicht mehr laden, da du kein VFS mehr hast. Bei INET gilt entsprechendes, wenn das System für die Treiberdatei Netzwerkzugriff braucht (geschenkt, geht unter Minix nicht). Will heißen: Du kannst nicht jeden Treiber neustarten, zumindest nicht unkonditionell.

Zweite Sache, und ja ich hacke gern darauf rum, es muss ja nichtmal ein böserartiges Programm sein, welches sich da in dein Treiberverzeichnis schreibt. Wer sagt denn, dass es nicht ein Fehler ist, den du beim Programmieren (Kompilieren) gemacht hast und ihn noch VOR dem Neustart beheben kannst? Oder wer verrät dir, dass beim Kopieren via Netzwerk der Dateistrom nicht abgerissen ist und die Datei unter Umständen nicht vollständig oder (UDP) fehlerhaft ist?

Das kann man zwar mit Prüf-/Signatursummen umgehen, ist aber trotzdem ein valider Punkt.

Und ja, ich merke schon, dass ich zu sehr Unix denke und du genau deswegen das, was ich sage, ohnehin ablehnst.

Gruß,
Sebastian

[FlashBurn]

Und ja, ich merke schon, dass ich zu sehr Unix denke und du genau deswegen das, was ich sage, ohnehin ablehnst.

Dem muss ich absolut widersprechen, denn ihr habt mich fast soweit, das ich das mit dem automatisch neuladen der Treiber doch lasse.

Das schrieb ich bereits und nahm mir die Freiheit, mich bereits vorauseilend für diese Aussage zu entschuldigen.

Dafür brauchst du dich nicht entschuldigen, aber ich denke mal ein Server-OS hat dann doch noch ein paar mehr Anforderungen als ein "einfaches" Consumer-OS und irgendwo muss man ja mal Abstriche machen

Zweite Sache, und ja ich hacke gern darauf rum, es muss ja nichtmal ein böserartiges Programm sein, welches sich da in dein Treiberverzeichnis schreibt. Wer sagt denn, dass es nicht ein Fehler ist, den du beim Programmieren (Kompilieren) gemacht hast und ihn noch VOR dem Neustart beheben kannst? Oder wer verrät dir, dass beim Kopieren via Netzwerk der Dateistrom nicht abgerissen ist und die Datei unter Umständen nicht vollständig oder (UDP) fehlerhaft ist?

Naja, ich sehe das Problem durchaus ein. Was ich aber auch sehe ist, dass man dieses Problem (fehlerhafter/bösartiger Code) eher schwierig bis gar nicht umgehen kann

Minix als Mikrokernel besteht auch aus solchen Servern (MM, FS, INET). Wenn du allerdings MM beendest, kannst du ihn mangels Speicherverwaltung nicht neustarten. Beendest du FS, kannst du die Treiberdatei nicht mehr laden, da du kein VFS mehr hast. Bei INET gilt entsprechendes, wenn das System für die Treiberdatei Netzwerkzugriff braucht (geschenkt, geht unter Minix nicht). Will heißen: Du kannst nicht jeden Treiber neustarten, zumindest nicht unkonditionell.

Naja, mit diesem Neustarten willst du ja "nur" nen abgestürzten Server neustarten und die Daten sind schon im Speicher vorhanden.
Wenn ich nen Treiber neustarten/updaten würde, dann muss natürlich der neue Treiber auch schon geladen sein. Deswegen sagte ich ja, das man dafür ein vernünftigen Weg braucht, damit das ganze klappt.

[Svenska]

Wenn der Treiber wegen Speicherfehlern (und ja, die treten auf!) abstürzt, dann nutzt dir dein Speicherabbild mal garnichts. Außerdem hast du ja nur einen Memdump des Treibers - und nicht die Treiberdatei im Speicher. Dazu musst du also Speicher verschwenden, indem du (zur Laufzeit überflüssige) Zusatzinformation im Speicher hältst.

Mal abgesehen davon brauchst du ne gute Abstraktion, dass dir ein Neuladen des HDD-Treibers nicht die Dateisysteme entreißt. Das würde Userspace-Programme stark verwirren. Außerdem - was machst du, wenn in diesem Zeitfenster ein Programm (Dateisystemtreiber!) gerade etwas auf Platte schreiben möchte und fsync() aufruft? Pufferst du das im RAM zwischen oder riskierst du das Dateisystem?

Ähnliches mit der Netzwerkhardware - wird ein Neuladen des Treibers die Karte auch neu initialisieren (eher ja, weil sonst is doof), aber was passiert, wenn die Karte gerade fleißig arbeitet und du ihr den Treiber entreißt? Nicht jede Hardware lässt sich jederzeit zuverlässig resetten.

Daher würde ich, wie von Erik auch vorgeschlagen, einen Treiberneustart nur dann erlauben, wenn die Hardware gerade nicht in Benutzung ist (d.h. Treiber können auch nur rekursiv entladen werden, wenn sie von anderen Treibern genutzt werden). Auf der anderen Seite heißt das, dass du gewisse Änderungen halt nur mit einem Systemneustart machen kannst. Halte die Bootzeit schön klein und das ist nicht so schlimm, wie es aussieht.

Gruß

[erik.vikinger]

Hallo,


das automatische Neustarten von Treibern, vor allem von jenen die das System braucht, ist schon ziemlich tricky. Da sollte man sich genau überlegen ob man das als erstes in ein Hobby-OS integriert. Der einzigst sinnvolle Weg ist auch nur möglich wenn die original Treiber-Datei im Speicher vorgehalten wird und zwar nicht nur mit einer guten Prüfsumme sondern mit echten Korrektur-Daten versehen (Reed-Solomon oder was ähnliches), Speicherfehler passieren wirklich!

Das mit dem automatischen übernehmen eines neuen Treibers (z.B. wenn ein Programmierer einen neuen kompiliert hat) ist nicht nur äußerst riskant sondern auch grob fahrlässig! Wenn Dein OS wirklich mal irgend jemand benutzt und durch dieses Sicherheitsleck tatsächlich ein Schaden entsteht könnte man den Programmierer eventuell tatsächlich vor ein deutsches Gericht bringen, gegen "grobe Fahrlässigkeit" hilft auch keine Beteuerung "Jeder darf mein Zeug benutzen aber ich übernehme keine Verantwortung!". Schon aus moralischer Sicht würde ich sagen das ein Programmierer immer etwas Verantwortung für seinen Code trägt. Also ich kann nur wiederholen das man so eine Funktion besser erst gar nicht programmiert. Bei Linux muss der Treiberprogrammierer auch ein "rmmod blubber; modprobe blubber;" ans Ende seines Build-Scriptes (oder sonstwas) packen und wird dafür auch root-Rechte haben müssen. Für einen Programmierer der gut genug ist einen Treiber zu programmieren sollte das auch nicht zu viel verlangt sein und ein normaler User/Admin fühlt sich sicher etwas wohler wenn er sich sicher sein kann das sein OS nur dann einen neuen Treiber akzeptiert wenn er das explizit abgesegnet hat. In meinem OS möchte ich dem Driver-Loader nur gestatten Treiber zu starten die in der Datenbank stehen und deren SHA256-Check-Summe noch stimmt. Zum Ändern der Datenbank wird man auf jeden Fall eine explizite Erlaubnis von root brauchen. Das diese Datenbank verwundbar ist wenn das System nicht läuft (und die Platte in einem anderen Rechner einbaut wird) ist mir klar aber zur Laufzeit einfach einen neuen Treiber automatisch zu akzeptieren geht IMHO nur wenn alles mit starker Kryptographie sehr gut abgesichert ist (und selbst dann könnte sicher nicht jeder Admin ruhig schlafen).

Was an Treibern so gefährlich ist? Ganz klar der uneingeschränkte HW-Zugriff. Selbst wenn ein Treiber nur seine HW kontrollieren kann so kann doch ein Ethernet-Controller-Treiber eine komplette Kopie des physischen RAMs in die weite Welt schicken oder ein HDD-Treiber einen solchen Memory-Dump irgendwo auf die Festplatte legen. Beide können aber auch den physischen Speicher mit neuen Daten überschreiben, insbesondere der Ethernet-Treiber kann da als aktive Hintertür benutzt werden (da könnte man durchaus einen kleinen Server implementieren der es einem externen Angreifer ermöglicht Deinen RAM zu analysieren und zu manipulieren). Das ist IMHO Risiko genug das es sich lohnt wenigstens mal ein klein wenig über die Sicherheit des Systems nachzudenken.


Grüße
Erik

[FlashBurn]

Also gut ihr habt mich überzeugt Wenn ein Treiber-Update stattfinden soll, wird für den Anfang ein Neustart notwendig sein.

Was mir noch so im Kopf rumschwirrt. Was macht man wenn man 2 unterschiedliche Treiber/Dateien für das gleiche Gerät hat? Einfach den ersten nehmen oder den neueren?

Das diese Datenbank verwundbar ist wenn das System nicht läuft (und die Platte in einem anderen Rechner einbaut wird) ist mir klar

Sorry, aber an sowas denke ich nicht mal. Wenn es um Sicherheit geht und es möglich ist die Platte auszubauen, an einen anderen PC anzuschließen, die Daten darauf zu manipulieren und die Platte dann wieder zurück zu packen. Wozu dann noch Sicherheit unter deinem OS? Das ein OS zur Laufzeit nicht manipulierbar sein sollte ist klar, aber wenn obiges möglich ist, dann ist das auch egal. Soll heißen wenn es so wichtig ist dass das OS läuft bzw. das die Daten darauf so wichtig sind, dann sollte dieses Szenario überhaupt nicht möglich sein. Ergo wird es einfach ignoriert

Ich mache mir auch keine Illusionen das mein OS irgendwann mal produktiv eingesetzt wird (ich schreibe an einem OS was vorallem und zuerst alte Hardware unterstützt bzw. darauf laufen soll). Ich mache das aus Spaß an der Sache und irgendwo muss man dann auch mal Abstriche machen. Sicherheit ist im Moment sogar ein verdammt großes Problem, da ich davon überhaupt keine Ahnung habe, auch nicht wie man bestimmte Sachen vernünftig macht, aber darüber mach ich mir eigentlich weniger Sorgen.

[Svenska]

Ich empfehle cat /proc/sys/net/ipv4/fuckups, einen Talk (knappe Stunde) vom letzten Chaos Communication Congress. Dort wird beschrieben, wie man durch eine Ansammlung kleiner, vereinzelter, an sich ungefährlicher Bugs in ein Netzwerk eindringen kann.
Warum? Unter anderem werden dort auch zwei Ethernet-Treiber missbraucht, um Payload als neues Paket an den Kernel weiterzureichen.

Der letzte Playstation 3 Hack basiert auf modifizierten USB-Geräten, die im USB-Treiber einen Buffer Overflow verursachen und damit code execution erlauben. Gegen physische Angriffe kann man sich nicht absichern (Festplattenverschlüsselung hilft nicht gegen Keylogger in der Tastatur), deswegen stehen solche Server auch in abgesicherten Rechenzentren und/oder abgeschlossenen Stahlschränken.

Bei deinem zwei-Treiber-ein-Gerät-Fall würde ich unterscheiden, ob du zwei verschiedene Treiber hast oder einen Treiber in verschiedenen Versionen. Im ersteren Fall würde ich entweder den spezielleren oder beide laden - einer kommt nicht an die Ressourcen ran und wird beendet - und im letzteren Fall halt die neuere Version.

Beispiel hierfür wäre "nvidia" gegen "vesa" - ersterer ist, auch wenn älter, sicherlich geeigneter - oder "Chipsatztreiber" gegen "PIO-IDE-Treiber". Das wird aber erst interessant, wenn du von den generischen Treibern wegkommst; bis dahin kannst du einfach die neuere Version starten (aber: manueller Override für den Fall, dass der neue nicht funktioniert!).

Gruß