Wie viel Energie
darf Schutz kosten?
Sicherheit ist eine der wichtigsten Anforderungen an moderne Computer. Nutzer*innen erwarten, dass die verwendete Software dem neuesten Sicherheitsstandard entspricht und Sicherheitslücken zeitnah behoben werden. Dies lässt sich in Anwendungen mittels Updates kurzfristig realisieren. Schwieriger wird es jedoch, wenn Schwachstellen nicht etwa in der Software, sondern in der Hardware verortet sind.
Ist ein Fehler in der Hardware für Sicherheitslücken verantwortlich, wird die Behebung dieser Schwachstelle deutlich komplexer. Denn durch ein einfaches Update lassen sich solche Fehler meist nicht beheben. Um weiterhin umfänglichen Schutz zu bieten, muss das Hardwaredesign angepasst und betroffene Komponenten ausgetauscht werden. Dies ist in der Regel mit einigen Kosten verbunden – und dabei gar nicht immer zwingend erforderlich. Sogenannte Mitigierungen können es ermöglichen, die betroffene Hardware weiter zu nutzen. Durch diese Maßnahmen lässt sich die Schwachstelle in der Regel nicht vollumfänglich beheben, jedoch wird die Angriffsoberfläche deutlich reduziert. Es findet also eine Art Abschwächung der Schwachstelle statt.
Spekulative Ausführung als Angriffspunkt
Welchen Schaden Hardware-Schwachstellen anrichten können, zeigten Fälle wie Spectre1 und Meltdown2. Um hier Attacken vorzubeugen, ist eine Vielzahl von Maßnahmen erforderlich.
Ansatzpunkt für diese Attacken ist die spekulative Ausführung, die moderne Prozessoren zur Performancesteigerung nutzen. Hierbei wird auf den Ausgang bestimmter Berechnungen, beispielsweise von Zugriffsberechtigungen auf Speicherinhalte, spekuliert. Diese Berechnungen sind oftmals sehr aufwendige Operationen und nehmen vergleichsweise viel Zeit in Anspruch. Anstatt zu warten, kann der Prozessor auch auf das Ergebnis spekulieren. So lässt sich die Ausführung erst einmal fortführen, während die eigentliche Berechnung parallel durchgeführt wird. Sobald diese dann beendet ist, wird evaluiert, ob das angenommene Ergebnis richtig war oder ob die Ausführung ab dem Punkt der nicht eingetretenen Spekulation erneut ausgeführt werden muss.
Wenn sensible Daten Spuren hinterlassen
Die Nutzung dieser spekulativen Ausführung setzt voraus, dass Ergebnisse aus der Prozessoreinheit erst dann für Anwendungen sichtbar sind, wenn alle Spekulationen auch überprüft wurden. Andernfalls können die vollständige Rückabwicklung und richtige Ausführung nicht garantiert werden. Allerdings sind potenziell falsche Zwischenergebnisse oder Daten, auf die eigentlich kein Zugriff erlaubt sein sollte, als „Spuren“ in der internen Mikroarchitektur der Prozessoren vorhanden und bleiben dort auch nach der Rückabwicklung bei falscher Spekulation bestehen, beispielsweise in den Caches, den kleinen Zwischenspeichern der Prozessoren. Eigentlich sind die Inhalte der Caches nicht für Anwendungen sichtbar. Jedoch gibt es sogenannte Seitenkanalattacken, die es Angreifenden ermöglichen, trotzdem auf deren Inhalte zuzugreifen. Durch diesen Umweg können Attacken auch die Zwischenergebnisse spekulativer Ausführung auslesen und erhalten damit beispielsweise Zugriff auf Daten, für die eigentlich keine Zugriffsberechtigungen vorliegen.
Durch Hardware-Schwachstellen können also private, sensitive Daten ausgelesen werden, die eigentlich durch Speicherschutzmaßnahmen geschützt sein sollen. Vollständig verhindert werden solche Attacken nur durch den Austausch der Prozessoren mit Modellen, deren Design entsprechend angepasst wurde. Damit aber auch bestehende Systeme geschützt werden, werden die eingangs bereits erwähnten Mitigierungen, also Abschwächungen, eingesetzt.
Abgeschwächt statt ausgetauscht
Mitigierungen verfolgen im Grunde zwei Ansätze. Zum einen kann die Nutzung der Spekulation an sicherheitskritischen Stellen eingeschränkt werden. Zum anderen kann die Angriffsoberfläche für solche Seitenkanalattacken reduziert werden. Dabei werden zusätzliche Softwarefunktionen eingeführt, die das Ausnutzen der Schwachstellen verkomplizieren, sodass entsprechende Attacken deutlich aufwendiger werden. Viele dieser Abschwächungen sind im Betriebssystem implementiert. Dieses hat als Schnittstelle zwischen Hardware und Anwendungen Zugriff auf die Speicherinhalte der Anwendungen und ist somit ein gutes Ziel für Angreifer, die ein System kompromittieren wollen.
Diese Schutzmaßnahmen sind sehr effektiv, haben aber auch starken negativen Einfluss auf die Performance und den Energiebedarf eines Systems. Wie hoch insbesondere der Energiebedarf aufgrund von Maßnahmen ansteigt, die die Gefahren durch Spectre und Meltdown eindämmen, hat ein Forschungsteam bereits 2021 erfasst.3 Es untersuchte verschiedene Funktionalitäten des Betriebssystems und analysierte, wie Schutzmaßnahmen deren Ausführung beeinflussen. Mit seinen Messungen zeigte das Team, dass sich die verschiedenen Schutzmaßnahmen je nach Funktion unterschiedlich stark auswirken und der zusätzliche Energiebedarf stark variiert. Auf der einen Seite ist bei 39 Prozent der Funktionen nur ein vergleichsweise geringer zusätzlicher Energiebedarf von unter fünf Prozent zu messen. Allerdings gibt es auch einige Funktionen, bei denen die Schutzmaßnahmen deutlich mehr zusätzliche Energie erfordern.
Wenn Anwendungen ein hohes Maß an Interaktion mit dem Betriebssystem aufweisen, kann der gemessene zusätzliche Energiebedarf von bis zu 72 Prozent deutlich ins Gewicht fallen. Dies betraf etwa ein Drittel der getesteten Funktionen. Eine hohe Interaktivität mit dem Betriebssystem ist je nach Domäne keine Seltenheit. Gerade bei netzwerkintensiven Anwendungen sind Aufrufe direkt ins Betriebssystem vielfach vorhanden. In diesen Bereichen sollten die Schutzmaßnahmen gezielt eingesetzt werden, um die Energiebilanz des Systems nicht unnötig zu verschlechtern. Denn nicht alle Anwendungen verarbeiten sensible Daten – so nehmen Betreiber*innen in diesen Fällen den erhöhten Energiebedarf unnötigerweise in Kauf. Daher sollten die Schutzmechanismen des Betriebssystems immer an den aktuellen Systemzustand und die ausgeführten Anwendungen angepasst werden.
Dynamischer Schutz in Linux
In aktuellen Linux-Systemen ist die Einstellung der Schutzmechanismen gegen Hardware-Schwachstellen größtenteils nur beim Start des Systems möglich. Eine Anpassung der Einstellung während der Laufzeit, die sich dynamisch und auf Grundlage der ausgeführten Anwendungen und deren Schutzbedürfnisse verändert, ist generell nicht vorgesehen. Um diese dynamische Anpassung in Linux zu realisieren, muss auch auf verschiedenen Systemebenen einiges angepasst werden. Zum einen müssen die Anwendungen bekannt machen, welchen Schutz sie benötigen. Dies kann von einem Systemservice gebündelt und an ein dediziertes Betriebssystemmodul übermittelt werden. Dieses Modul führt basierend darauf die Einstellungsanpassungen durch. Hierfür kann auf Code-Patching zurückgegriffen werden. Damit wird die Implementierung des Betriebssystems zur Laufzeit verändert und die Schutzmaßnahmen können dynamisch hinzugefügt und auch wieder entfernt werden.
Mithilfe der dynamischen Anpassungen von Schutzmechanismen in Linux können die teils starken Auswirkungen der softwarebasierten Abschwächung von Hardware-Schwachstellen auf den Energiebedarf eines Systems reduziert werden. Das hier vorgeschlagene System wurde in der Forschungsgruppe „Betriebssysteme und Systemsoftware“ der Ruhr-Universität Bochum (RUB) im Rahmen einer Masterarbeit implementiert und mit minimalem Overhead in Linux integriert. Die damit erzielbaren Effizienzgewinne hängen dabei sowohl von der Hardware als auch von den ausgeführten Anwendungen ab.
Insgesamt zeigen die genannten Analysen und weitere Arbeiten, dass Schutzmaßnahmen mit signifikantem zusätzlichen Energiebedarf verbunden sein können. In Zeiten, in denen wir alle zu ressourcenschonendem Verhalten aufgerufen sind, muss auch der Energiebedarf von Systemen mit in den Blick genommen werden. Das erlaubt es uns, hohen Energiedarf nicht nur zu identifizieren, sondern auch Maßnahmen zu ergreifen, um diesen möglichst gering zu halten. Dynamische Anpassungen von Betriebssystemschutzmechanismen können ein Baustein sein, um nicht nur sichere, sondern auch effiziente Systeme zu betreiben.
Über die Autorin
Henriette Hofmeier ist seit 2022 wissenschaftliche Mitarbeiterin in der Forschungsgruppe „Betriebssysteme und Systemsoftware“ von Prof. Dr.-Ing. Timo Hönig an der Ruhr-Universität Bochum (RUB). Dort forscht sie unter anderem im Rahmen der DFG-geförderten Projekte NEON (465958100) und Memento (502228341) an der Verbesserung der Energieeffizienz von Sicherheitsmechanismen in Betriebssystemen. Für ihre Masterarbeit wurde sie mit dem Preis für herausragende Abschlussarbeiten der Fachgruppe Frauen und Informatik ausgezeichnet, mit dem die Fachgruppe die Leistungen junger Frauen in der Informatik sichtbar machen und engagierten Frauen in der IT einen Anreiz bieten will, sich in einer größeren Öffentlichkeit zu präsentieren.
Deep dive
Für alle, die tiefer in die Materie einsteigen wollen, hier ein paar weitere Leseempfehlungen.
Die gesamte Arbeit von Henriette Hofmeier unter dem Titel „Dynamic Reconfiguration of Hardware-Vulnerabilities in the Linux Kernel“ finden Sie hier als PDF:
https://sys.cs.fau.de/publications/2022/hofmeier_22_thesis.pdf
Artikel „Meltdown and Spectre, explained“ von Matt Klein:
https://medium.com/@mattklein123/meltdown-spectre-explained-6bc8634cc0c2
Dominik Herrmann, Mitglied des .inf-Fachbeirats, empfiehlt zu diesem Thema das Tutorial von Dr. Michael Schwarz auf YouTube:
https://www.youtube.com/watch?v=xteiXOpEjXs
1 Kocher et al. (2019), Spectre attacks: Exploiting speculative execution. In the Proceedings of the 40th IEEE Symposium on Security and Privacy (SP ’19).
2 Lipp et al. (2018), Meltdown: Reading kernel memory from user space. In the Proceedings of the 27th USENIX Security Symposium (USENIX Security ’18).
3 Herzog, et al. (2021), The Price of Meltdown and Spectre: Energy Overhead of Mitigations at Operating System Level. In the Proceedings of the 14th European Workshop in Systems Security (EuroSec ’21).
