You must log in or register to comment.
Warum sollte man die Treiber auch rauswerfen? Zur Laufzeit stören ungenutzte Treiber nicht. Und ich habe lieber 38 Millionen ungenutzte Zeilen Code im Kernel, als mich auf die Suche nach dem richtigen Treiber zu machen, wenn ich eine Maus anschließe.
Es macht schon Sinn ab und an mal aufzuräumen. Kaum einer hat noch den SCSI-Flachbettscanner von 1994 im Einsatz, synct regelmäßig Daten auf einen Palm Pilot oder möchte seine 3D-Spiele mit einer Voodoo2-Grafikkarte beschleunigen. Die Treiber sind ja noch da, man muss sie dann halt manuell installieren, aber so wirklich brauchen tut man das alles auf einem modernen Rechner nicht
Die Treiber sind ja noch da, man muss sie dann halt manuell installieren
„Da”. Wo? Was bringt es mir, wenn die Treiber „da” sind, aber ich nicht drauf zugreifen kann, weil ich kein Bild aus meiner Voodoo2-Grafikkarte kriege? Oder nicht aufs Internet zugreifen kann, weil der Treiber für meine WLAN-Karte nicht da ist?
„Ist doch total einfach”, sagt der Arch-Nutzer. „Du musst nur booten, das Terminal öffnen, blind mit cURL den richtigen Treiber (28-stellige Versionsnummer nicht vergessen) herunterladen, Kernel-Parameter ändern, neu booten und hoffen, dass du dich nirgends vertippt hast.“
Ich weiß ehrlich gesagt gar nicht mehr, wann ich das letzte Mal irgendwelche Weichware mit curl runterladen musste 🫣 Und das sage ich als militanter Bogn-Nutzer.
Der Kernel hat ja auch alle Treiber.
Gruselig.
Ich hab mal meinen Kernel selber kompiliert, und im
make menuconfigEwigkeiten lang irgendwelchen dubiosen Scheiß weggeklickt.Keiner ist in der Lage, 40.000.000 Zeilen Code zu warten. Keiner. Selbst Linux Torvalds sagt, dass er bei den PRs einfach den Developern vertraut. Das sieht man auch bei bösartigen Commits wie diesem hier:
Oder der bekannten xz backdoor, die nur durch absoluten Zufall gefunden wurde, nachdem sie bereits in Debian testing, Arch, Gentoo etc. angekommen war. Mit xz werden sogar die Kernel Archives komprimiert, das ist kein Spaß.
Weiter mit systemd, glibc, gnu coreutils, GNU linker, grub, … so viel Code, den keiner ganz versteht.
Und innerhalb des Kernels gibt es keine Schutzmechanismen! Wenn da eine Schwachstelle in nem Absurden uralten Treiber ist, kann das zu einem Kernel Exploit führen und Angreifer haben Zugriff auf alles.
Bei Microkerneln könnte sowas nicht passieren.
Bis dahin ist eine einfache Möglichkeit, mit einem
/etc/modprobe.d/hardening.confalles Mögliche am Laden zu hindern. Am Ende müsste man den Kernel aber eben recht minimal selber bauen.Gibt es irgendwo eine Anleitung dazu, wie man herausfindet, welche Treiber im laufenden Betrieb tatsächlich benötigt werden und den Rest komplett rauszuschmeißen?
Oder, sagen wir, alles was in einem Laptop von 2020 definitiv nicht mehr gebraucht wird?Ja das wäre super gut. Meines Wissens gibts es nix.
Wäre auch bei der Installation sinnvoll.
Ein großer Monokernel, erkennt die Hardware, baut eine build-Option und baut von da an den Kernel selber, signiert, packt, installiert.
Letzteres ist wahrscheinlich bei Distros wie Gentoo einfacher, da sie darauf spezialisiert sind, das Kompilieren so einfach wie möglich zu machen.
Hab ein bisschen recherchiert und das gibt es doch:
modeprobed-dbläuft im Hintergrund und schreibt alle Kernel-Module, die genutzt werden, in eine Textdatei. Nachdem man dann einmal alles gemacht hat wofür man den PC nutzt, kann man beim Kompilieren die Textdatei als Input verwenden und kriegt nur die Teile des Kernels, die man braucht.Cool!
Bei Microkerneln könnte sowas nicht passieren.
Ja, sobald GNU Hurd endlich erscheint wird Milch und Honig in allen Ländern fliessen und gebratene Hühner fliegen uns ins Maul. Dieses Jahr wird es sicher soweit sein…
RedoxOS ist glaube ich schneller ;)
