Linux 5.14 mit "geheimem" Speicher und sicherem Hyperthreading
Seite 3: Streng geheimer Speicher
Ein weiteres "Langzeit-Projekt", das jetzt nach rund zwei Jahren Entwicklungszeit und 23 Versionen im Mainline-Kernel angekommen ist, ist der neue, vorerst allerdings standardmäßig deaktivierte System-Call memfd_secret(). Userspace-Prozesse können mit ihm einen Speicherbereich schaffen, der durch keinen anderen Systemteil einsehbar ist – nicht einmal durch den Kernel selbst. Prädestiniert ist ein solcher Speicherbereich für das Ablegen von geheimen und besonders schützenswerten Informationen wie beispielsweise kryptographischen Schlüsseln oder Passwörtern. Selbst Angriffen auf die virtuelle Speicherverwaltung und auch Hardware-Bugs wie Spectre soll dieser Mechanismus widerstehen.
Nach einem Aufruf von memfd_secret() erhält der aufrufende Prozess einen File-Descriptor auf den neuen geheimen Speicher. Nach diesem ersten Registrieren des Speichers legt ein Aufruf von ftruncate() dessen Größe fest. Ein nachfolgendes Ausführen von mmap() spiegelt die "virtuelle" Datei schließlich in den Adressraum des aufrufenden Prozesses.
Der Kernel seinerseits entfernt den geheimen Speicher aus einer direkten Speicher-Map (direct map) und markiert diesen zusätzlich, um ihn vor irrtümlichem Wiederverwenden zu schützen. Mit diesen Aktionen verliert der Kernel den Zugriff auf den Speicher. Theoretisch könnte der Kernel den geheimen Speicher auch wieder in die "direct map" zurückholen. Dazu fehlt aber unter normalen Umständen eine entsprechende vorgefertigte Funktion.
Ein kompromittierter Kernel könnte dieses Zurückholen allerdings implementieren – etwa im Zuge eines Schadcode-Befalls, bei dem die im Kernel-Code bereits vorhandenen Anlagen um entsprechende Funktionen ergänzt werden. Hier wird deutlich: Das Konzept des geheimen Speichers, ein reiner Software-Mechanismus, funktioniert nur in einem vertrauenswürdigem Umfeld. Für mehr Schutz wären Hardware-Features notwendig, ähnlich denen, die AMDs SEV und Intels SGX zum Absichern des Speichers für virtualisierte Maschinen nutzen. SEV und SGX sind auch auf einem kompromierten Hostsystem noch sicher; memfd_secret() hingegen nicht.
Konsequenzen von memfd_secret()
Der geheime Speicherbereich ist, da der Kernel ihn nicht mehr "sieht", nicht in System-Calls einsetzbar. Ebenso können DMA-Operationen (Direct Memory Access) den Speicher nicht nutzen. Da sowohl System-Calls als auch DMA die geheimen Daten in den Kernel beziehungsweise in Kernel-sichtbaren Speicher tragen würden, was den Sinn eines "geheimen Speichers" allgemein in Frage stellen würde, sind diese Einschränkungen allerdings rein theoretischer Natur.
Ganz praktische Auswirkungen kann das Konzept auf lieb gewonnene Gewohnheiten haben. Um den geheimen Speicher vor allen ungewollten Blicken abzuschirmen, ist er auf physischen RAM beschränkt und soll nicht auf Festplatte ausgelagert werden können. Daher entschieden sich die Entwickler, den Ruhezustand ("Hibernate") des Systems bei aktivem memfd_secret() zu deaktivieren. Denn beim Hibernate schreibt das System seinen RAM-Inhalt temporär auf die Festplatte und schaltet sich aus. Bei aktivem memfd_secret() weiterhin nutzbar ist hingegen der Standby-Modus, bei dem die Speicherinhalte im (weiterhin mit Strom versorgten) RAM verbleiben.
memfd_secret() standardmäßig deaktiviert
Trotz der Aufnahme in den Mainline-Kernel bringen die Kernel-Entwickler ihrer Schöpfung memfd_secret() kein blindes Vertrauen entgegen: memfd_secret() ist standardmäßig deaktiviert. Erst die Option secretmem_enable auf der Kernel-Kommandozeile macht den System-Call nutzbar. Das Entwickler-Team befürchtet, dass die Performance des Systems einbrechen könnte, wenn die "direct map" beschädigt werden könnte. Eingriffe ins Memory-Management sind grundsätzlich heikel, und selbst kleine Fehler können immense Auswirkungen haben. Daher ist es besser, das Feature nur dort gezielt zu aktivieren, wo es wirklich eingesetzt werden soll.
Zudem könnten die geheimen Speicherbereiche das verfügbare physische RAM verknappen. Im schlimmsten Fall, so die Befürchtung einiger Entwickler, könnte im RAM ein durch geheimen Speicher zerstückelter Flickenteppich entstehen. Im Extremfall könnte das System letztlich mehr mit Swapping als mit dem Erbringen seiner eigentlichen Aufgabe beschäftigt sein. Ob sich solche Befürchtungen bewahrheiten, müssen die Zeit und die gesammelten Erfahrungen mit Anwendungen zeigen, die das Feature in Zukunft nutzen werden.
