Die Betreuer der
Stable-Kernel-Series haben die Kernel-Versionen
2.6.25.12 und
2.6.25.13 freigegeben. Erstere enthält knapp fünfzig Korrekturen in verschiedenen Bereichen des Linux-Kernels; die neuen Änderungen bei 2.6.25.13 sind hingegen vornehmlich im Netzwerk-Subsystem angesiedelt. Die Freigabe-Mails der beiden jüngsten Linux-Versionen der 25er-Serie erwähnen weder CVE-Nummern noch Sicherheitskorrekturen explizit; in beiden Mails rät Greg Kroah-Hartman den Anwendern von selbst kompilierten 2.6.25-Kerneln aber zum Update auf die neuen Versionen ("
Any users of the 2.6.25 kernel series should upgrade to this version").
Das heißt aber nicht, dass die neuen Versionen nicht doch Sicherheitskorrekturen enthalten; einige der Kernel-Entwickler haben erst kürzlich in einer längeren Diskussion (1, 2) durchblicken lassen, dass sie zwar durchaus bereit sind, öffentlich zu (sicherheitsrelevanten) Fehlern und deren Korrektur zu stehen. Mit dem in Sicherheitskreisen üblichen Drumherum – etwa dem Schreiben detaillierter Fehlerberichte oder die Freigabekoordination mit Linux-Distributoren – wollen sich zumindest einige der Kernel-Entwickler aber nicht herumschlagen. So scheint es auch bei 2.6.25.13 zu sein, denn zumindest eine Änderungen am PPP-Code korrigiert eine Sicherheitslücke, die derzeit als CVE-2008-2750 diskutiert wird; Fedora, OpenSuse und Ubuntu haben das Problem in den vergangenen Tagen bereits durch Kernel-Updates behoben.
Das zeigt wieder einmal, dass Anwender, die die Kernel-Entwicklung nicht intensiv verfolgen, mit einem Distributions-Kernel meist am besten bedient sind. Ähnlich hatte es auch Greg Kroah-Hartman kürzlich in einer Mail durchblicken lassen. Anwender, die anhand der von ihm bei der Veröffentlichung mitgegebenen Informationen nicht entscheiden könnten, ob sie das Kernel-Update einspielen müssen oder nicht, sollten besser einer Firma das Bereitstellen von Updates überlassen und nicht selbst Kernel einspielen. ("Take a look at the words I used, if someone can't determine if they should upgrade or not based on that, then they need to rely on a company to provide updates for them, and not be running their own kernels because they really have no clue about system management.").
Anzeige
 |
Durch einige Foren und Webseiten geisterte in den vergangenen Tagen die Nachricht, Foxconn hätte das BIOS und speziell deren ACPI-Tabellen eines Mainboards absichtlich so manipuliert, dass die Boards nicht mit Linux zusammenarbeiten. Kernel-Hacker Matthew Garrett erklärt in zwei Blog-Posts (1, 2) die Problematik genauer und stellte dabei klar, dass kein Vorsatz seitens Foxconn vorliegt; vielmehr seien auch Fehler im Linux-Kernel für die mit dem Foxconn-Board auftretenden Probleme mitverantwortlich.
Auch auf der Linux-Kernel Mailing Liste (LKML) gab es in den vergangenen Wochen wieder allerlei Diskussionen um ACPI. Ausgelöst wurden die durch die von Suse-Entwickler Thomas Renninger gefundenes und analysiertes Überhitzungsprobleme beim Einsatz von Linux auf einem HP-Notebook. Daraufhin schlug Renninger einige Änderungen und ACPI BIOS Guidelines for Linux vor. Len Brown, der Verwalter des Linux-ACPI-Subsystems, ist mit einigen der Lösungsvorschläge und Ideen aber nicht ganz einverstanden.
Kernel-Log-Staccato
- Elias Oltmanns hat auf der LKML Patches vorgestellt, durch die der Kernel die Schreib-/Leseköpfe von Festplatten zügig parkt, falls etwa das Notebook zu stark beschleunigt wird ("Disk shock protection").
- Kurz nachdem VIA Harald Welte als Open-Source-Berater engagierte, hat das Unternehmen Dokumentation zu zwei Chipsätzen und der Padlock-Engine neuerer VIA-CPUs auf VIAs im Frühjahr gestarteten Linux-Portal veröffentlicht.
Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich auch in den vorangegangen Ausgaben des Kernel-Logs auf heise open:
Ältere Kernel-Logs finden sich über das Archiv oder die Suchfunktion von heise open.
(thl/c't)
Unternehmens-
