Linux durchbricht 40-Millionen-Zeilen-Marke
Die Kernel-Quellen wachsen ungebrochen weiter. Rauswurf von Treibern für schlankeren Code wird eher nicht klappen.
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.“
Gruselig.
Ich hab mal meinen Kernel selber kompiliert, und im make menuconfig Ewigkeiten 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.conf alles 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.
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 ;)
