Linux 5.14 mit sicherem Hyper-Threading und geheimem Speicher

Die Veröffentlichung von Linux 5.14 erfolgte zwischen zwei symbolträchtigen Jahrestagen: Am 25. August 1991 kündigte Linus Torvalds Linux erstmals an und am 17. September desselben Jahres erschien sein erstes Kernel-Release. Auch nach 30 Jahren ist im Linux-Kernel immer noch Platz für Neuerungen.

So steuert Microsoft einen neuen Display-Treiber (hyperv_drm) bei, der für Hyper-V gedacht ist und auch mit Wayland zusammenarbeitet. Ballast verliert Linux 5.14 mit dem veralteten IDE-Treibersystem, das die Entwickler entfernt haben.

Kekssteuerung

Core-Scheduling hat es nach über drei Jahren Entwicklungszeit in den Mainline-Kernel geschafft. Das soll die Sicherheit bei Prozessoren mit Simultaneous Multithreading (SMT) beziehungsweise Hyper-Threading verbessern, bei denen jeder CPU-Kern zwei Threads quasiparallel verarbeiten kann. 2018 zeigte die berüchtigte Spectre-Attacke, dass ein bösartiger Thread Daten eines anderen Threads über Seitenkanäle wie den gemeinsam benutzten Cache ergaunern kann. Deshalb lässt Core-Scheduling nur Threads mit derselben Vertrauensstufe auf demselben CPU-Kern laufen. Bei einem Cloud-Provider können dadurch Kunden so aufgeteilt werden, dass sie sich keine Cores im Hyper-Threading teilen. So lässt sich SMT nutzen, ohne dass die Kunden sich gegenseitig ausspionieren können.

Intern führt der Kernel hierzu „Cookies“ ein, die das Core-Scheduling Prozessen zuweist. Nur Prozesse mit identischen Cookies dürfen auf denselben Cores im Hyper-Threading laufen. Implementiert ist das API zum Core-Scheduling in der Kernel-Funktion prctl(). Über die hinzugekommene Option PR_SCHED_CORE erzeugt man die Cookies im Kernelspace und weist sie initial einem Prozess zu. Der Core-Scheduler regelt über die ptrace()-Berechtigung, ob Prozesse Cookies beziehen oder an diese zuweisen dürfen. Im Userspace können sich die Prozesse keine eigenen Cookies anlegen, ansonsten verwalten sie ihre Cookies autark.

Ist kein Prozess mit passendem Cookie vorhanden, geht der Thread in den Wartezustand. Das mindert die Effizienz des Hyper-Threadings, aber die CPU-Auslastung ist so immer noch besser als ohne Hyper-Threading.

Streng geheimer Speicher

Der neue System-Call memfd_secret() ist ein weiteres Langzeitprojekt und jetzt nach 23 Versionen im Mainline-Kernel angekommen. Mit der Funktion können Userspace-Prozesse einen Speicherbereich schaffen, den kein anderer Teil des Systems einsehen kann – nicht einmal der Kernel soll diese Speicherbereiche lesen können. Prädestiniert ist ein solcher Speicherbereich für besonders schützenswerte Informationen wie beispielsweise kryptografische Schlüssel. Selbst Angriffen auf die virtuelle Speicherverwaltung und auch Hardware-Bugs wie Spectre soll dieser Mechanismus widerstehen.

Mit einem Aufruf von memfd_secret() erhält der aufrufende Prozess einen File-Descriptor auf den neuen geheimen Speicher. Mit weiteren System-Calls spiegelt man diese virtuelle Datei in den Adressraum des aufrufenden Prozesses. Der Kernel seinerseits entfernt den Bereich aus seiner direkten Speicher-Map („Direct Map“) und markiert ihn zusätzlich als gesperrt. Dadurch verliert der Kernel Zugriff auf den Speicher. Theoretisch könnte der Kernel den geheimen Speicher auch wieder in die Direct Map zurückholen. Dazu fehlt aber passender Code – den aber ein kompromittierter Kernel mitbringen könnte.

Trotz der Aufnahme in den Mainline-Kernel ist memfd_secret() standardmäßig deaktiviert. Die Entwickler befürchten Performance-Einbrüche bei Beschädigung der Direct Map. Zudem verknappen geheime Speicherbereiche das verfügbare physische RAM, da sie nicht in den Swap-Bereich ausgelagert werden können. (ktn@ct.de)