Die Neuerungen von Linux 4.13
Seite 2: Wichtige Verbesserungen
Infrastruktur: /proc/cpuinfo nennt jetzt nur noch Basistakt
Die Datei /proc/cpuinfo liefert auf 32- und 64-Bit-x86-Systemen in der Zeile "cpu MHz" jetzt den Basistakt des verwendenden Prozessors. Der Wert ist damit nun eine Konstante und wird nicht mehr von der Zeit beeinflusst, die der Prozessor kurz vor der Abfrage mit niedrigeren oder höheren Taktfrequenzen lief. Bislang änderte sich die MHz-Angabe auf vielen Systemen immer wieder, denn die zum Hoch- und Runtertakten des Prozessors zuständigen Cpufreq-Governer konnten dort einen Mittelwert bereitstellen, der sie auf die ein oder andere Weise auf den zuletzt genutzten Frequenzen berechnen. In einer ausführlichen Begründung zur Entfernung bezeichnen die Entwickler diese Taktfrequenzangabe als "inakkurat". Dennoch: Daran interessierte Anwender finden den Wert nach wie vor im Sysfs, wo er jetzt sogar besser und bei Bedarf häufiger berechnet wird.
Die Entwickler raten Anwendern aber zum Einsatz des Programms turbostat, das in den Kernel-Quellen steckt. Das Werkzeug liefert deutlich präzisere Angaben zur Frage, wie lange der Prozessor und seine Kerne in langsamen oder schnelleren Betriebszuständen verbracht oder gar geschlafen hat. Das Tool beobachtet den Prozessor standardmäßig in fünf Sekunden langen Intervallen; anschließend spuckt es aber so viele Messwerte aus, dass die erste Interpretation ein wenig Einarbeitung erfordert.
Das ebenfalls in den Kernel-Quellen enthaltene Werkzeug cpupower unterstützt jetzt Ryzen und andere AMD-Prozessoren der Familie 0x17. Dieses Werkzeug liefert Informationen zur eingesetzten Cpufreq-Regelung sowie Minimal- und Maximal-Takt des Prozessors. Darunter sind auch die Eckdaten, unter welchen Umgebungsbedingungen wie viele Prozessor-Kerne auf Taktfrequenzen über dem Basistakt wechseln können; AMD nennt das Turbo Core, Intel hingegen Turbo Boost.
Ext4: Mehr Dateien pro Verzeichnis
Verzeichnisse auf Ext4-Dateisystemen sollen statt zirka 10 Millionen Datei- und Verzeichniseinträgen in Zukunft rund 2 Milliarden Einträge aufnehmen können. Das ist dem "Largedir Feature" zu verdanken, das mit den Änderungen am Ext4-Dateisystem zum Kernel stieß; im Begleittext betont der Betreuer der Ext4-Codes allerdings, in der Praxis würden Performance-Probleme auftreten, wenn man so viele Einträge in einem Verzeichnis anzulegen versuche.
Die Largedir-Erweiterung wurde ursprünglich von den Machern des Distributed File Systems (DFS) Lustre programmiert und lässt sich bislang nur mit Entwicklerversionen der Ext-Dateisystemwerkzeuge E2fsprogs aktivieren. Beides gilt auch für ein ebenfalls neues Feature, durch das Ext4 ein erweitertes Attribut (Extended Attribute/EA) in einem eigenen Inode speichern kann. Darauf baut eine weitere Änderung auf, durch die Ext4 solche auch Xattr genannten Attribute zusammenlegen (deduplizieren) kann. Das spart nicht nur Speicherplatz, sondern verbessert Cache-Effekte und damit letztlich auch die Performance.
Für einen Geschwindigkeitszuwachs kann auch eine weitere Änderung sorgen: Ext4 verarbeitet Discard-Operationen jetzt parallel. Solche setzt der Ext4-Code ab, wenn man Dateisysteme mit der Option discard einbindet, um beispielsweise SSDs gleich beim Löschen von Dateien auf freigewordenen Bereiche hinzuweisen. Bei Tests des Entwicklers reduzierte das neue Vorgehen eine im ungünstigsten Fall auftretende Wartezeit von 17 Sekunden auf knapp 5 Sekunden. Diese Werte zeigen ganz nebenbei, zu welchen Latenzen diese Mount-Option führen kann. Wer solche Geschwindigkeitseinbußen vermeiden will, lässt die Mount-Option besser links liegen; stattdessen ruft man besser zu einem günstigen Zeitpunkt fstrim auf, denn auch darüber erfahren SSDs oder mit Thin Provisioning arbeitende Netzwerkspeicher von freigewordenen Bereichen.
SMB3 für Windows- & Samba-Freigaben
Beim Einbinden von Dateifreigaben von Samba- oder Windows-Servern mit Hilfe des CIFS-Dateisystems nutzt dieses nun standardmäßig Version 3 des Protokolls Server Message Block (SMB) (u. a. 1, 2). Damit folgen die Entwickler einer Empfehlung von Microsoft und CERT, die vom Einsatz des bislang verwendeten SMB1 abraten: Dieses auch als Common Internet File System/CIFS bekannte Protokoll hat bekannte und nicht so einfach behebbare Schwächen, die jüngst mehrere Erpressungstrojaner als Verbreitungsvektor genutzt haben.
Sollte der Server den moderneren Protokolldialekt nicht unterstützen, scheitert ein Einhängen mit der Fehlermeldung "mount error(112): Host is down". Dann muss man den CIFS-Code über die Mount-Option vers=1.0 zur Verwendung von SMB1 zwingen. Server-seitig gibt es eigentlich schon länger Support für das mächtigere und auch effizientere SMB3: Samba unterstützt es seit Version 4.0 und Microsoft seit Windows 8 und Windows Server 2012. Zum Einhängen der Dateifreigaben vieler NAS und Router ist die genannte Mount-Option aber erforderlich, denn sie implementieren vielfach nur SMB1.
FORTIFY_SOURCE-Schutz für Zeichenketten
Linux 4.13 bringt eine Reihe von Detailverbesserungen, um die Systemsicherheit weiter zu verbessern. Eine davon ist eine Schutz für die in string.h definierten Funktionen zur Handhabung von Zeichenketten. Durch sie soll der Kernel einige Pufferüberläufe beim Handling von Zeichenketten gleich beim Kompilieren oder später im Betrieb erkennen und abfangen können. Durch diesen Ansatz hätte der Kernel etwa ein Ausnutzen der als CVE-2016-3858 geführten Lücke unterbinden können, die Android auf Nexus 5X und 6P betraf. Der Ansatz dieser Schutztechnik ähnelt stark der Glibc-Funktion _FORTIFY_SOURCE=1. Moderne Distributionen nutzen diese typischerweise beim Kompilieren von Userspace-Code, um einige beim String-Handling auftretenden Buffer Overflows gleich beim Übersetzen oder später zur Laufzeit zu erkennen.
Interna beim Kompilieren verwürfeln
Eine weitere neue Sicherheitstechnik ist das "Randstruct GCC-Plug-in", mit dem der Compiler das Layout von Feldern ausgewählter Strukturen randomisiert. Das verspricht, Angreifern die Rechteausweitung zu erschweren, weil sie einige dazu dienliche und häufiger genutzte Codestellen nicht mehr so leicht im Speicher aufspüren können.
Der Ansatz ist allerdings vornehmlich für jene interessant, die ihre Kernel selber kompilieren; in diese Klasse fallen etwa Firmen wie Facebook oder Google, die in ihren Rechenzentren eigene Kernel-Images nutzen. Für Linux-Distributoren wie Debian, Fedora, Ubuntu & Co. ist das neue Plug-in weniger interessant, denn sie müssten den zum Randomisieren genutzten Zufallswert veröffentlichen, damit Anwender zum Distributions-Kernel passende Module kompilieren können. Durch solch eine Veröffentlichung haben Angreifer dann aber wieder alle Informationen zur Hand, um zur Rechteausweitung dienliche Stellen wieder leicht aufzuspüren.
Details zu diesen und anderen Vor- und Nachteilen des Ganzen liefern ein LWN.net-Artikel und einige Commits rund um die Aufnahme des Plug-ins (1, 2, 3). Wie der eingangs erwähnte Fortify-Schutz und eine Reihe anderer jüngst in den Kernel integrierten Sicherheitstechniken entstand auch dieses Plug-in beim Grsecurity-Projekt; verschiedene Kernel-Entwickler haben es jetzt im Rahmen des Kernel Self Protection Project (KSPP) grundlegend überarbeitet, damit es die Qualitätsansprüche von Linus Torvalds & Co. erfüllt und in den offiziellen Kernel einziehen kann.
