Kernel-Log – Was 2.6.37 bringt (4): Architektur- und Infrastruktur-Code

Bei der Freigabe von 2.6.37-rc6 hat Linus Torvalds vergangene Woche nochmal betont, den Linux-Kernel 2.6.37 nach den Urlaubstagen rund um den Jahreswechsel freigeben zu wollen. Zudem laufe es derzeit nicht ganz so ruhig, wie er es gerne hätte – das gilt vermutlich auch für den in Kürze erwartete siebte Vorabversion, denn kürzlich wurde eine Neuerung rückgängig gemacht, die die Verteilung der Hardware-Ressourcen hatte verbessern sollen.

Einen Überblick über diese und zahlreiche anderen Änderungen rund um den plattformspezifischen und Infrastruktur-Code des Kernels liefert der folgende vierte Teil der Kernel-Log-Mini-Serie "Was 2.6.37 bringt". Der erste Teil der Serie hatte sich bereits mit den Änderungen rund um Grafik-Hardware beschäftigt, der zweite mit denen rund um Dateisysteme und der dritte mit Anpassungen am Netzwerk- und Storage-Code. Zwischen den Jahren folgt der fünfte und letzte Teil, der sich mit weiteren Treibern und der sie umgebenden Kernel-Subsysteme beschäftigt.

Bye bye Big Kernel Lock

Einer Neuerung von 2.6.37 ließ Linus Torvalds besondere Aufmerksamkeit zukommen, indem er sie bei der Vorstellung der ersten Vorabversion von 2.6.37 explizit erwähnte: Die Kernbereiche des Linux-Kernels sind nun nicht mehr auf das Big Kernel Lock (BKL) angewiesen. Dabei handelt es sich um eine Locking-Technik aus den Anfangszeiten der Multiprozessor-Unterstützung von Linux, die Konflikte beim gleichzeitigen Zugriff auf zentrale Datenstrukturen im Kernel vermeidet. Sie war damals vergleichsweise einfach umsetzbar, sperrt aber subsystemübergreifend – das wirkt sich bei Systemen mit vielen Prozessorkernen negativ auf die Performance aus und kann zu langen Latenzen bei Systemaufrufen führen, die nicht nur im Echtzeit-Umfeld unerwünscht sind.

Über eine neue Option lassen sich jetzt sogar Kernel komplett ohne BKL konfigurieren. Auf eine Handvoll noch auf das BKL angewiesene Treiber und Dateisysteme muss man dann aber verzichten – die meisten sind für aktuelle Systeme eher uninteressant, wenn man vom UDF-Dateisystem absieht. Patches, damit auch das unter anderem für manche DVDs benötigte Dateisystem ohne das BKL arbeitet, kamen aber zu spät zur Aufnahme bei 2.6.37 und dürften in 2.6.38 einziehen.

Prozess-Management und Tracing

Der Scheduler versucht nun ein Verschieben von Echtzeit-Tasks auf andere Prozessorkerne zu vermeiden. Bei der Prozessverteilung rechnet der Scheduler die Zeit, die der Prozessor mit der Verarbeitung von IRQs verbraucht, nicht mehr dem gerade aktiven jeweiligen Prozess zu, damit der nicht weniger Zeit als vorgesehen erhält.

Über den Schalter "-V" kann das Probe-Subkommando von Perf nun an Probe-Points alle lokalen Variablen auflisten; mit Hilfe von "--externs" lassen sich alle globalen Variablen auflisten, die zugänglich sind. Neu ist auch die rudimentäre Unterstützung für Module in "perf probe".

Die neuen Jump-Label (u. a. 1, 2, 3, 4, 5) sollen den Overhead rund um die An- und Ausschaltfunktionen für Tracepoints weiter verringern – Details erläutert ein kurzer Artikel bei LWN.net. Im Feldtest zeigte sich allerdings, dass das Ganze doch noch nicht wie gewollt funktioniert, daher wird die Technik vor der Fertigstellung von 2.6.37 möglicherweise noch deaktiviert.

Security

Der Crypto-Daemon des Kernels bietet nun ein Interface für AEAD (Authenticated Encryption with Associated Data). Über einen Sysctl-Aufruf lässt sich nun festlegen, ob normale Anwender oder nur solche mit der Capability CAP_SYS_ADMIN Zugriff auf die Syslog-Informationen haben, die sich mit dmesg auslesen lassen; das soll Angriffe erschweren, die Informationen aus dem Syslog zur Hilfe nehmen.

Ursprünglich sollten Lesebeschränkungen für /proc/kallsyms Angreifern das Leben weiter erschweren – die Änderung wurde aufgrund von Problemen mit Userland-Anwendungen aber zurückgezogen. Hintergründe dazu liefert LWN.net im Artikel "Making attacks a little harder"; einige Tage nach Rücknahme der Änderung wurde eine Umsetzung mit Capabilities vorgeschlagen, doch auch die fand fürs erste keinen Anklang.

Virtualisierung

Unter den von den Xen-Entwicklern für Linux 2.6.37 beigesteuerten Änderungen war auch der "Initial Domain Support", der den Kernel um Funktionen zum Betrieb als Dom0 erweitert (u. a. 1, 2, 3, 4, 5, 6, 7). Xen-Anwendern ist das aber fürs erste keine große Hilfe, da der Treiber zum Aufsetzen der Xen-Backends fehlt, über die die Gastsysteme auf Datenträger und Netzwerk zugreifen. Die Xen-Entwickler planen, den dafür zuständigen Code zur Aufnahme bei 2.6.38 einzusenden, sodass mit dieser Version der Dom0-Betrieb möglich sein könnte. Beim diesem und dem jetzt in den Kernel integrierten Xen-Code handelt es sich jedoch um eine abgespeckte Variante, die weniger Funktionen bietet als aktuelle Xen-Versionen oder der XenServer von Citrix.