Kernel-Log – Was 2.6.36 bringt (3): Infrastruktur

Inhaltsverzeichnis

Am Mittwoch früh hat Linus Torvalds die sechste Vorabversion von Linux 2.6.36 freigegeben. Dabei deutete er an, bald 2.6.36 freigeben zu wollen, vielleicht aber doch noch eine weitere Vorabversion einzuschieben.

Das Kernel-Log nimmt das zum Anlass, die Mini-Serie "Was 2.6.36 bringt" mit der Beschreibung der Neuerungen rund um Dinge wie Speicherverwaltung, Build-System und die Unterstützung für verschiedene CPU- und System-Architekturen fortzusetzen. Der erste Teil der Serie hatte sich mit den Änderungen rund um Grafik-Hardware beschäftigt, der zweite mit Dateisystemen, Storage- und Netzwerk-Hardware; ein vierter Teil zu den Änderungen rund um ACPI, PCI, Power-Management und den Treibern für USB, FireWire, V4L/DVB und Co. wird die Mini-Serie in einigen Tagen abschließen.

Security

Nachdem sich die Entwickler der 2006 von Novell offengelegten AppArmor mehrere Jahre erfolglos um die Aufnahme des Kernel-Codes der Sicherheitserweiterung bemüht hatten, stieß dieser nun in der Version 2.6.36 endlich zum Kernel (u. a. 1, 2, 3, Dokumentation). Ähnlich wie SELinux kann AppArmor Anwendungen auf festgelegte Aktionen beschränken; Angreifer, die über eine Sicherheitslücke etwa in einer Server-Software Zugang zum System erhalten, können daher nur begrenzt Schaden anrichten.

AppArmor steht in dem Ruf, leichter administrierbar zu sein als SELinux. Letzteres wird von Red Hat favorisiert und kommt unter anderem bei Red Hat Enterprise Linux (RHEL) und Fedora zum Einsatz. Novell hatte sich lange auf AppArmor konzentriert, 2007 aber von der eigenen AppArmor-Entwicklungsabteilung getrennt und seit 2008 auch SELinux eingesetzt. Dadurch verlangsamte sich die AppArmor-Entwicklung erheblich, bis John Johansen ihr Anfang des Jahres neuen Schwung verlieh und schließlich auch die Aufnahme in den offiziellen Kernel vorantrieb. Johansen arbeitete früher bei Novell und kümmert sich derzeit bei Canonical maßgeblich um die Integration von AppArmor in Ubuntu.

Zahlreiche Anläufe und mehrere Jahre hatte auch das aus TALPA hervorgegangene Fanotify gebraucht, bevor Torvalds es nun integrierte (u. a. 1, 2, 3). Es baut auf dem bei 2.6.31 integrierten Fsnotify auf und bietet Einstiegspunkte, über die sich beispielsweise Virenscanner einklinken können, um Dateien beim Zugriff auf Schadsoftware zu überprüfen, bevor deren Inhalt ausgeliefert wird ("On-Access-Scan"). Einige Hintergründe zur Funktionsweise von Fanotify sowie den Problemen früherer Fanotify-Ausführungen liefern mehrere LWN.net-Artikel (u. a. 1, 2, 3).

[Update 14.10.2010, 09:30] Nur einige Tage vor der Fertigstellung von Linux 2.6.36 haben die Entwickler die Userspace-Schnittstellen von Fanotify kurzfristig deaktiviert, um noch einige Unzulänglichkeiten beseitigen zu können, die teilweise auch das ABI betreffen (1, 2, 3) – dadurch ist Fanotify vorerst nicht nutzbar. Fehlerbeseitigung und Re-Aktivierung der Userspace-Schnittstellen sind für Kernel 2.6.37 vorgesehen; unklar ist noch, ob diese Patches möglicherweise auch in einen der Stable-Kernel der 2.6.36-Serie einziehen werden. [/Update]

Memory- und Thread-Management

Erheblich verändert und in weiten Teilen neu geschrieben haben die Kernel-Entwickler den Out of Memory (OOM) Killer, der bei Speichermangel Prozesse abschießt, damit das System weiterarbeiten kann (1, 2, 3). Durch diese Änderungen gilt die OOM-Feinjustage via /proc/<pid>/oom_adj nun als "deprecated" und soll im August 2012 verschwinden. Weitere Hintergründe zu den Änderungen am OOM liefert LWN.net in dem Artikel "Another OOM killer rewrite".

Integriert haben die Kernel-Hacker auch die "Concurrencey Managed Workqueues", welche die Handhabung von Kernel-Threads optimieren (u.a. 1, Dokumentation). Dadurch soll der Kernel die Ressourcen effizienter nutzen, besser skalieren und auf vielen Systemen mit weniger Threads auskommen – letzteres werden auch Anwender bemerken, denn dadurch verkürzt sich die Liste der bei ps -A ausgegeben Kernel-Threads. Weitere Vorteile sowie Gründe für die Änderungen liefert der Entwickler in einer detaillierten Mail zu seinen Patches und im Rahmen des Git-Pull-Request; LWN.net hat im Herbst letzten Jahres einen Artikel zu den Concurrencey Managed Workqueues verfasst.