Moderne Computer basieren auf einem Fundament aus komplexen Instruktionen, die der Hardware genau sagen, was sie tun soll. Diese Instruktionen bilden einen Vertrag zwischen der Software, die wir schreiben, und den physischen Chips, auf denen sie läuft. Seit Jahrzehnten verlassen sich Ingenieure auf sorgfältiges Testen, um sicherzustellen, dass dieser Vertrag eingehalten wird, indem sie prüfen, ob ein Prozessor exakt so reagiert, wie es ihre Designer vorgesehen haben. Da diese Chips jedoch immer komplexer geworden sind, stoßen die alten Methoden der Überprüfung zunehmend an ihre Grenzen. Die schiere Größe der möglichen Kombinationen von Aktionen, die ein Chip ausführen kann, ist zu gewaltig geworden, als dass Menschen sie einzeln prüfen könnten. Als Reaktion darauf haben Forscher eine Technik namens Fuzzing entwickelt. Ursprünglich für Software entwickelt, beinhaltet diese Methode das Einspeisen eines massiven Stroms von zufälligen oder leicht veränderten Eingaben in ein System, um zu sehen, ob es abstürzt. In der Welt der Hardware bedeutet dies, einen Prozessor mit Millionen von seltsamen Instruktionssequenzen zu bombardieren, um zu sehen, ob er abstürzt, sich unerwartet verhält oder eine verborgene Sicherheitslücke offenbart.

Eine neue Studie führt die verstreuten Bemühungen von Forschern zusammen, die diese Technik auf drei verschiedenen Komplexitätsebenen auf Hardware angewendet haben. Die Forscher, die an Universitäten in den Vereinigten Staaten arbeiten, analysierten, wie Fuzzing derzeit eingesetzt wird, um alles zu testen – von den High-Level-Regeln, die das Verhalten eines Prozessors steuern, bis hin zur Low-Level-Verkabelung, die den Chip funktionsfähig macht. Sie fanden heraus, dass, obwohl die grundlegende Idee, einer Maschine wahllos Daten zuzuführen, funktioniert, die spezifischen Werkzeuge und Strategien, die benötigt werden, um Bugs zu finden, sich drastisch ändern, je nachdem, welche Ebene der Hardware getestet wird. Ihre Arbeit zeigt, dass das Feld derzeit fragmentiert ist, da verschiedene Gruppen unterschiedliche Methoden verwenden, die schwer miteinander vergleichbar sind, und sie weist auf eine Zukunft hin, in der künstliche Intelligenz und eine bessere Koordination zwischen diesen Ebenen die Hardware-Verifizierung weita-viel effektiver machen könnten.

Die Forscher ordneten die Landschaft des Hardware-Fuzzings in drei verschiedene Schichten ein, von denen jede ihre eigenen Herausforderungen hat. Die erste Schicht ist die Befehlssatzarchitektur (Instruction Set Architecture), also die Menge der Befehle, die ein Prozessor versteht. Werkzeuge auf dieser Ebene behandeln den Prozessor als Black Box, was bedeutet, dass sie nicht in den Chip hineinsehen können; sie können lediglich Befehle senden und die Ergebnisse beobachten. Das Ziel hierbei ist es, Instruktionen zu finden, die der Prozessor zwar ausführt, die aber nie offiziell dokumentiert wurden, oder Fälle zu finden, in denen der Prozessor sich anders verhält, als es sein Handbuch vorgibt. Da die Tester die internen Abläufe nicht sehen können, verlassen sie sich auf den Vergleich des Outputs des Prozessors mit einem vertrauenswürdigen Referenzmodell – einem separaten Programm, das simuliert, was der Prozessor tun sollte. Wenn der echte Chip und die Simulation voneinander abweichen, wird ein Bug gemeldet. Die Studie ergab, dass, während zufälliges Testen einige Fehler finden kann, die effektivsten Werkzeuge eine Mischung aus zufälliger Generierung und strukturierten Regeln verwenden, um unnütze Daten zu überspringen und sich auf die Bereiche zu konzentrieren, in denen Fehler am wahrscheinlichsten verborgen sind.

Die zweite Schicht ist die Mikroarchitektur, die sich mit den internen, verborgenen Mechanismen befasst, wie der Prozessor diese Instruktionen ausführt. Hier trifft der Chip blitzschnelle Entscheidungen, um die Geschwindigkeit zu erhöhen, wie etwa das Vorhersagen, welche Instruktion als Nächstes kommt, oder das temporäre Speichern von Daten in einem Cache. Diese internen Verhaltensweisen sind normalerweise nicht Teil des offiziellen Vertrags mit der Software, können aber Sicherheitslücken erzeugen. Beispielsweise könnte ein Prozessor geheime Daten versehentlich durch das Timing seiner Operationen preisgeben. Das Testen dieser Schicht ist schwierig, da die Bugs meist keine Abstürze oder Fehler sind, sondern subtile Informationslecks. Die Studie zeigte, dass Werkzeuge, die auf diese Schicht abzielen, oft auf spezifische Verhaltensmuster setzen, die als gefährlich bekannt sind, anstatt auf reiner Zufälligkeit zu basieren. Sie konstruieren Testsequenzen, die darauf ausgelegt sind, diese spezifischen internen Mechanismen auszulösen, und messen dann winzige Zeitunterschiede, um zu sehen, ob ein Geheimnis geleakt wurde. Die Forscher merkten an, dass das Finden dieser Bugs ein tiefes Verständnis des internen Designs des Chips erfordert und dass Werkzeuge, die lediglich zufällig raten, hier oft unwirksam sind.

Die dritte Schicht ist die Register-Transfer-Ebene (Register-Transfer Level), also der tatsächliche Code, der zur Konstruktion des Chips verwendet wird, bevor dieser gefertigt wird. In dieser Phase existiert der Chip nur als digitaler Bauplan, und Ingenieure können jeden einzelnen Draht und jeden Schalter sehen. Dies bietet die höchste Sichtbarkeit und ermöglicht es den Testern, exakt zu messen, wie viel des Designs bereits exploriert wurde. Werkzeuge auf dieser Ebene können die Eingabedaten basierend auf Echtzeit-Feedback aus der Simulation mutieren, wie etwa der Frage, wie viele neue Zustände des Chips besucht wurden. Die Studie fand heraus, dass diese Ebene zwar das präziseste Testen ermöglicht, die hier verwendeten Werkzeuge jedoch oft langsam sind, da die Simulation eines Chips viel Zeit in Anspruch nimmt. Darüber hinaus entdeckten die Forscher ein erhebliches Problem in der Art und Weise, wie diese Werkzeuge ihren Erfolg melden. Verschiedene Werkzeuge nutzen unterschiedliche Wege, um die Abdeckung (Coverage) zu messen, was einen direkten Vergleich nahezu unmöglich macht. Ein Werkzeug könnte behaupten, einen Bug nach einer Million Tests gefunden zu haben, während ein anderes dasselbe Ergebnis mit nur zehntausend Tests erzielt; ohne eine standardisierte Methode, was „Abdeckung“ eigentlich bedeutet, sind diese Zahlen jedoch schwer zu interpretieren.

Das Paper identifiziert mehrere kritische Lücken im aktuellen Stand der Technik. Ein wesentliches Problem ist die Abhängigkeit von „Golden Reference Models“, also den vertrauenswürdigen Simulationen, die verwendet werden, um zu prüfen, ob der echte Chip korrekt arbeitet. Wenn das Referenzmodell selbst fehlerhaft ist, könnte das Fuzzing-Tool echte Bugs übersehen oder Fehlalarme auslösen. Dies ist besonders problematisch für die Mikroarchitektur-Ebene, in der kein perfektes Referenzmodell existiert, da die internen Abläufe oft nicht vollständig dokumentiert sind. Die Forscher hoben auch hervor, dass es dem Feld an einer gemeinsamen Sprache für die Berichterstattung von Ergebnissen mangelt. Ohne standardisierte Benchmarks und Metriken ist es schwierig zu wissen, ob ein neues Werkzeug wirklich besser als ein altes ist oder ob es lediglich etwas anderes misst. Sie beobachteten zudem, dass die meisten Werkzeuge immer noch darauf beschränkt sind, jeweils nur eine Schicht einzeln zu testen, wodurch die komplexen Interaktionen übersehen werden, die entstehen, wenn die High-Level-Instruktionen auf die Low-Level-Hardwaremechanik treffen.

Mit Blick in die Zukunft schlagen die Autoren vor, dass die nächste Generation des Hardware-Fuzzings intelligenter und vernetzter sein muss. Sie schlagen den Einsatz künstlicher Intelligenz vor, um bessere Test-Inputs zu generieren, wobei man über einfache Zufälligkeit hinausgehen und Sequenzen erstellen soll, die eher dazu geeignet sind, das System auf interessante Weise unter Stress zu setzen. Sie fordern zudem die Entwicklung skalierbarer Referenzmodelle, die die Komplexität moderner Chips bewältigen können, ohne dass ein unmöglicher Aufwand an manueller Arbeit nötig ist. Vielleicht am wichtigsten ist ihre Vision eines hybriden Ansatzes, bei dem Fuzzing-Tools auf verschiedenen Ebenen miteinander kommunizieren. Ein Tool auf Instruktionsebene könnte eine verdächtige Kommandosequenz an ein Mikroarchitektur-Tool weitergeben, welches wiederum ein spezifisches Timing-Muster an ein Low-Level-Tool weiterreichen könnte, wodurch eine kontinuierliche Untersuchungskette entsteht, die das gesamte System abdeckt. Die Forscher glauben, dass die Community durch die Standardisierung der Ergebnismessung und die Integration dieser verschiedenen Ebenen von einer fragmentierten Sammlung von Werkzeugen zu einem einheitlichen, systematischen Ansatz gelangen kann, der unsere zunehmend komplexen Computer sicher und zuverlässig macht.