zurück zum Artikel

Linux-Entwickler optimieren weiter um Prozessor-Bugs herum

Linux-Entwicklern optimieren weiter um Prozessor-Bugs herum

Durch "Core Scheduling" soll sich Hyper-Threading bald auch sicher mit CPUs nutzen lassen, die bekannte Schwachstellen aufweisen.

Auf der derzeit stattfindenden Linux Plumbers Conference ging es gleich in mehreren Sessions um Sicherheit und Performance in Zeiten von Prozessor-Sicherheitslücken wie Spectre, Meltdown, L1TF und MDS. So arbeiten die Entwickler daran, Intels Hyper-Threading wieder sicher mit Linux nutzen zu können – das muss man bei vielen Intel-Prozessen derzeit zum vollständigen Schutz vor den Prozessor-Schwachstellen deaktivieren, die seit Anfang 2018 bekannt wurden.

Ferner wurden auch Kernel-Änderungen grob umrissen, um die Arbeitsspeicherbereiche verschiedener Prozesse strikter voreinander zu trennen; dadurch sollen Bösewichte weniger Schaden anrichten können, falls in Zukunft ähnliche Prozessor-Sicherheitslücken bekannt werden. Von diesen Ansätzen ist aber noch keiner reif für die Aufnahme in den Kernel.

Screenshot einer Präsentation zu Core Scheduling

Mit Core Scheduling führt der Kernel gruppierte Prozesse nie parallel mit anderen auf der gleichen CPU aus.

(Bild: Screenshot einer Präsentation zu Core Scheduling [1] )

Dank dem maßgeblich von einem Intel-Mitarbeiter entwickelten "Core-Scheduling" [2], von dem einige Teile zur Aufnahme in Linux 5.4 vorgesehen sind, soll sich Hyper-Threading (HT) auch auf Prozessoren mit Lücken wie L1TF und MDS sicher nutzen lassen. Durch den Ansatz lassen sich Prozesse in Gruppen bündeln, in denen ein Angriff von einem auf den anderen Prozess keine Gefahr darstellt. Zu einer Gruppe gehörende Prozesse führt der Scheduler dann auf HT-tauglichen CPU-Kern parallel aus, aber nie gleichzeitig mit Prozessen, die anderen Gruppen oder gar keiner angehören.

Das ist vor allem für Cloud-Anbieter interessant, damit diese einer Virtual Machine (VM) zwei virtuelle CPUs zuteilen können, die der Kernel parallel auf dem HT-tauglichen CPU-Kern ausführt. So lässt sich dessen Leistungspotenzial ausschöpfen, ohne die VMs manuell bestimmten CPUs zuzuweisen (Pinning), damit eine VM eines Kunden nicht die eines anderen angreifen kann. Das Core Scheduling hat indes einige Tücken und Overhead, daher wird es explizit zu aktivieren sein.

c't/Thorsten Leemhuis

Dieses Kissenmikrofon werfen sich die Diskussionsteilnehmer gegenseitig durch den Raum zu.

(Bild: c't/Thorsten Leemhuis)

Auf der Konferenz wurden noch einige Unklarheiten rund um den Ansatz geklärt, die Entwickler jetzt mit Patches angehen wollen [3]. Wie bei der Linux Plumbers Conference (LPC) gewohnt erfolgten solche Diskussionen mit einer "Catchbox" – einem kubischen Kissenmikrofon, das sich die Teilnehmer quer durch den Vortragsraum zuwerfen können, ohne das irgendwer Beulen davonträgt.

Einige Details zum Core-Scheduling erläutert ein LWN.net-Artikel aus dem Frühjahr [4]. Video-Aufzeichnungen von den drei LPC-Sessions, die sich um Core-Scheduling drehen (1 [5], 2 [6], 3 [7]), wollen die Veranstalter demnächst bei YouTube veröffentlichten. Der schon voriges Jahr von einem Amazon-Mitarbeiter vorgeschlagene Ansatz des "Co-Scheduling" [8], der umfassender ist als Core-Scheduling und weitere Einsatzmöglichkeiten abdeckt, hat fürs Erste den Kürzeren gezogen.

Im Vortrag Kernel Address Space Isolation [9] stellten verschiedene Entwickler ihre Ideen vor, um den vom Prozessen erreichbaren Arbeitsspeicher mit Tricks wie separaten Page Tables zu reduzieren. Das verspricht einige Angriffswege, die Prozessor-Sicherheitslücken ausnutzen, die Wirkungsgrundlage zu entziehen: Von Kernel und anderen Prozessen verwendeter Arbeitsspeicher wird dadurch noch schwieriger zu erreichen.

Präsentations-Screenshot

Die Entwickler der Ansätze wollen erstmal Grundlagen schaffen und werden dabei zeigen müssen, dass die den Aufwand wert sind.

(Bild: Präsentations-Screenshot [10] )

Die diskutierten Ansätze heißen KVM Address Isolation (das mit Address Space Isolation [ASI] arbeitet) [11], Process Local Memory [12], Namespace Local Memory und Kernel Page Table and Context Consolidation. Details zu den Wirkungsweisen finden sich in Präsentationsfolien der Sessions [13]. Die dort geführten Diskussionen zeigen aber, dass die Ansätze tiefgründige Umbauten erfordern würden, die eine zentrale, performancekritische Infrastruktur komplexer machen – Wortbeiträge ließen dabei durchblicken, dass einige zentrale Kernel-Entwickler daran zweifeln, ob die zusätzliche Sicherheit diesen ganzen Aufwand wert ist.

Der Veranstalter haben dem Autor einen kostenlosen Zugang zur Linux Plumbers Conference gewährt.

(thl [14])


URL dieses Artikels:
http://www.heise.de/-4519704

Links in diesem Artikel:
[1] https://linuxplumbersconf.org/event/4/contributions/285/attachments/252/466/Core_Scheduling.pdf
[2] https://lore.kernel.org/lkml/cover.1559129225.git.vpillai@digitalocean.com/
[3] https://lore.kernel.org/lkml/20190910142717.GA1855@sinkpad/
[4] https://lwn.net/Articles/780703/
[5] https://linuxplumbersconf.org/event/4/contributions/430/
[6] https://linuxplumbersconf.org/event/4/contributions/285/
[7] https://linuxplumbersconf.org/event/4/contributions/417/
[8] https://lore.kernel.org/lkml/20180907214047.26914-1-jschoenh@amazon.de/
[9] https://linuxplumbersconf.org/event/4/contributions/277/
[10] https://linuxplumbersconf.org/event/4/contributions/277/attachments/283/489/Kernel_ASI_2.pdf
[11] https://lore.kernel.org/lkml/1562855138-19507-1-git-send-email-alexandre.chartre@oracle.com/
[12] https://lore.kernel.org/lkml/FD3482AC-3FB0-41DE-9347-5BD7C3DE8B11@amacapital.net/T/
[13] https://linuxplumbersconf.org/event/4/contributions/277/attachments/283/489/Kernel_ASI_2.pdf
[14] mailto:thl@ct.de