Die Neuerungen von Linux 4.15
Seite 6: Sicherheitstechniken & Infrastruktur
AMDs Speicherverschlüsselung: Schritt zwei von drei
Mit einigen aktuellen AMD-Prozessoren kann Linux jetzt den Arbeitsspeicher von Virtual Machines (VMs) so verschlüsseln, dass weder Host noch andere VMs an die Daten herankommen, die VMs in dem von ihnen genutzten Teil des RAMs ablegen (u. a. 1, 2, 3, 4, 5, 6). Das gelingt über AMDs "Secure Encrypted Virtualization" (SEV). Diese Technik baut auf der Speicherverschlüsselungstechnik "Secure Memory Encryption" (SME) auf, die Linux seit Version 4.14 zusammen mit Epyc-Prozessoren oder dem für Business-PCs gedachten Ryzen Pro beherrscht.
Aber: Um SEV einsetzen zu können, muss auch der Hypervisor die Technik unterstützen. Die Patches zum Support von SEV mit dem Linux-eigenen Hypervisor KVM haben den Einzug in 4.15 allerdings verpasst und sollen erst in Linux 4.16 folgen. Einige Eckdaten zu SEV finden sich in Abschnitten, die jüngst zur Dokumentation stießen. Weitere Hintergründe zu AMDs Speicherverschlüsselung erläutern das Kernel-Log zu Linux 4.14 und die dort genannten Quellen.
Prozessor schränkt Zugriff ein
Linux unterstützt jetzt User-Mode Instruction Prevention (UMIP). Zukünftige Intel-Prozessoren sollen damit verhindern können, dass Userspace-Programme einige CPU-Instruktionen verwenden, die vorwiegend für Kernel gedacht sind (1, 2, 3, 4, 5, 6, 7, 8). Die Technik versperrt Anwendungen dadurch den Zugang zu manchen Prozessorinterna, die Angreifern oder Schadsoftware dienlich sein können.
Der KVM-Support für UMPI fehlt allerdings noch, denn auch die dafür zuständigen Änderungen kamen Torvalds zu spät und sollen erst bei 4.16 folgen. Ein weiteres Problem: Aktuelle Versionen von DOSEMU2 und Wine nutzen die von UMIP blockierten Instruktionen auf legitime Weise; eine Emulation fängt das teilweise ab und fordert zum Wechsel auf besser mit UMIP harmonierenden Versionen auf. Unklar ist noch, in welchen Prozessoren sich UMIP finden wird. Indizien sprechen dafür, dass Intel die Technik bei CPUs mit dem Codenamen "Cannon Lake" einführen wird.
Kernel Live Patching wird flexibler
Durch das "Shadow Variables API" sollen sich per Kernel Live Patching (KLP) Sicherheitslücken, die eine Erweiterung der Datenstrukturen erfordern, die die modifizierten Codebereich verwenden, jetzt auch zur Laufzeit beheben lassen. Das gelingt über Schattenfelder, die KLP an die bisherigen Datenstrukturen hängt, die davon abgesehen unverändert bleiben. Über diese Felder erreicht der Code separat abgelegte Schattenvariablen, die zusätzliche Daten aufnehmen. Details hierzu finden sich im Kommentar und der Dokumentationsänderung eines Commits.
Ebenfalls neu sind die "(un)patch callbacks". Damit kann der Kernel Funktionen aufrufen, bevor oder nachdem ein Livepatch angewendet oder revidiert wurde. Dadurch lassen sich auch Assembler-Code anpassen und globale Daten sicher ändern. Weitere Details zu diesem Ansatz liefert der Kommentar und die Dokumentationsänderung eines anderen Commits.
Noch mehr Sicherheit
Der Kernel bringt jetzt ein weiteres Prüfverfahren mit, das Überläufe von Referenzzählern erkennt. Angreifer lösen solche "Reference-Count Overflows" manchmal gezielt aus, um sich darüber zusätzliche Rechte zu verschaffen. Der Kernel bringt schon länger Code mit, um solche Überläufe zu erkennen. Der über die Kernel-Option "REFCOUNT_FULL" aktivierbare Ansatz reduziert aber die Performance signifikant, daher bleibt er bei vielen Kernel-Konfigurationen deaktiviert. Der neue, bislang nur auf 32- und 64-Bit-x86-Prozessoren arbeitende Ansatz hat hingegen einen vernachlässigbaren Overhead. Distributionen dürften sich daher weniger scheuen, ihn standardmäßig zu aktivieren; der neue Ansatz prüft aber in einigen Fällen nicht ganz so genau wie REFCOUNT_FULL. Details hierzu liefern ein Commit-Kommentar und ein LWN.net-Artikel. Das Feature wurde schon in 4.14 integriert, aber aufgrund eines Problems dort nochmal lahmgelegt. Der Fehler wurde jetzt korrigiert und die Funktion daraufhin freigegeben.
Eine ganze Reihe kleinerer Umbauten soll die Gefahr reduzieren, dass Log-Meldungen, Sysfs-Dateien oder andere Stellen per ASLR (Address Space Layout Randomization) zerhackte Speicheradressen verrät, die bei Angriffen auf den Kernel dienlich sein können (u. a. 1, 2, 3, 4, 5, 6, 7, 8).
Über neue Eingriffspunkte für Linux Security Modules (LSM) lassen sich Berechtigungen zur Verwendung von BPF und BPF-Programmen feiner regeln. Ebenfalls neu: Multi Program Support für Cgroup+bpf und ein Cgroup v2 Controller, der den Zugriff auf Devices regeln kann.
Durch Umbauten an den User-Namespaces lassen sich jetzt statt nur 5 bis zu 340 verschiedene Mappings definieren, über die sich User- und Gruppen-IDs von Containern auf IDs des Host abbilden lassen.
Einige weitere Änderungen rund um Sicherheit nennen die Kommentare der Haupt-Git-Merges der Subsysteme Audit, Crypto, Integrity, Security, SELinux.
Infrastruktur-Änderungen
Die Kernel-Entwickler habe weitere Umbauten vorgenommen, um das Jahr-2038-Problem zu vermeiden, das mit 32-Bit-Kernel-Images auftritt.
Einen schnelleren Kernel-Bau verspricht eine Detailänderung an Kbuild, die über Shell-Aufrufe gefüllte Variablen in einem Cache speichert.
Das neue Taint-Flag "TAINT_AUX" ist vornehmlich für Distributoren gedacht, die den Kernel in bestimmten Situationen als "Tainted" (beschmutzt/befleckt) kennzeichnen wollen. Einige Enterprise-Distributoren machen das beispielsweise, sobald man Funktionen oder Kernel-Module verwendet, deren Einsatz der Support-Vertrag nicht abdeckt.
Details zu anderen Neuerungen im Bereich Infrastruktur finden sich in den wichtigsten Commits der Subsysteme Cgroup, Documentation, Kbuild, Kselftest, Locking, Modules, RCU (Core), Scheduler und Timers (1, 2).
