google/silifuzzFuzzt CPU-Implementierungen, indem es Testeingaben aus Software-Proxys generiert und sie dann auf realer Hardware ausführt, um Mikroarchitektur-Defekte und Errata zu erkennen.
SiliFuzz ist ein System, das CPU-Defekte durch Fuzzing von Software-Proxys (wie CPU-Simulatoren oder Disassembler) findet und die angesammelten Testeingaben (auch als Corpus bekannt) anschließend in großem Umfang auf echten CPUs ausführt. SiliFuzz befindet sich in der Entwicklung; weitere Details finden Sie im Paper.
Fuzzing ist eine Technik, bei der ein Ziel (eine Anwendung oder eine API) mit einer großen Anzahl spontan erzeugter Testeingaben getestet wird. Ziel ist es, diese Eingaben so interessant und vielfältig wie möglich zu gestalten, um Randfälle auszulösen. Mit anderen Worten: Fuzzing zielt darauf ab, die kombinierte Codeabdeckung zu maximieren. Codeabdeckung kann unterschiedliche Bedeutungen haben, z. B. welche Basisblöcke ausgeführt werden oder welche Pfade im Programm genommen werden.
Im Sinne von SiliFuzz ist ein Proxy jedes Software- oder Hardwaresystem, das sich in Bezug auf bestimmte Aspekte der Ziel-CPU ähnlich verhält, z. B. ein CPU-Emulator oder ein Disassembler. Ein Proxy wird benötigt, wenn wir keine Coverage-Informationen direkt vom Ziel sammeln können.
Durch die Anwendung von Fuzzing-Techniken auf einen Proxy können wir eine Reihe von Testeingaben (Corpus) erzeugen, die im Proxy ein interessantes Verhalten hervorrufen. Unsere zugrunde liegende Annahme ist, dass sich dies in ein ähnlich interessantes Verhalten im Ziel übersetzt. Mehr dazu in der .
Eine Sammlung von Eingaben, die zum Testen des Ziels verwendet wird, wird als Corpus bezeichnet.
Ein einigermaßen großer Corpus enthält Millionen von Eingaben und wird normalerweise in mehrere nicht überlappende Teile, sogenannte Shards, aufgeteilt.
Ein SiliFuzz-Snapshot beschreibt eine kurze Sequenz von CPU-Instruktionen sowie einen Anfangszustand der CPU-Register und des Speichers, um diese Sequenz deterministisch auszuführen. Ein typischer Snapshot enthält weniger als 100 Bytes Code und läuft in Mikrosekunden, kann aber beliebig groß sein. Snapshots werden als Protocol-Buffer silifuzz.proto.Snapshot gespeichert.
Snapshots werden typischerweise aus den Eingaben einer Fuzzing-Engine erstellt. Für CPU-Testzwecke werden diese Eingaben gefiltert, um alle nicht-deterministischen Snapshots zu eliminieren. Mehr dazu in der Dokumentation.
Ein Endzustand beschreibt die Inhalte von Registern und Speicher, die am Ende einer Snapshot-Ausführung erwartet werden. Wenn der Snapshot auf verschiedenen CPU-Mikroarchitekturen unterschiedlich ausgeführt wird, hat er mehrere erwartete Endzustände.
Ein Snap ist eine In-Memory-Darstellung eines Snapshots, die vom Runner einfach geladen und ausgeführt werden kann. Snaps werden normalerweise von einem Reading Runner von der Festplatte geladen. Das On-Disk-Format von Snaps entspricht im Wesentlichen dem In-Memory-Format, außer dass native Zeiger durch Offsets ersetzt werden. Details siehe dieser Header. Dieses Format wird oft als relocatable bezeichnet. Jeder Snap enthält genau einen erwarteten Endzustand, d. h. Snaps sind mikroarchitekturspezifisch. Mehr dazu in der Dokumentation.
Der Runner ist eine Binärdatei zum Testen eines einzelnen CPU-Kerns. Ein Runner verarbeitet einen Corpus-Shard, führt darin wiederholt zufällige Snaps aus und prüft, ob der erwartete Endzustand erreicht wird. Der Runner ist ein Single-Thread-Prozess.
Der Orchestrator ist ein Prozess, der mehrere Runner steuert. In einer typischen Konfiguration führt der Orchestrator kontinuierlich einen Runner pro logischem CPU-Kern aus, sammelt alle von den einzelnen Runner-Prozessen erzeugten Fehler und meldet sie.
Siehe diese Datei für die Liste der unterstützten Mikroarchitekturen.
SiliFuzz läuft auf x86_64- und aarch64-Linux-Systemen. Es wurde mit Linux-Kernelversionen 5.x und 6.x getestet. Es gibt keine Garantie, dass es mit älteren Kernelversionen kompatibel ist. Die Legacy-vsyscall-ABI muss deaktiviert sein, um Fehlalarme zu vermeiden.
Eine nicht abschließende Liste von Bugs und Defekten, die SiliFuzz gefunden hat.
Ein Logik-Bug ist ein ungültiges CPU-Verhalten, das einer bestimmten CPU-Mikroarchitektur oder einem bestimmten Stepping innewohnt. SiliFuzz hat die folgenden Bugs identifiziert:
Ein (elektrischer) Defekt ist ein ungültiges CPU-Verhalten, das nur auf einem oder mehreren Chips auftritt. SiliFuzz hat die folgenden Defekte gefunden, die wir im Paper beschrieben haben:
git clone https://github.com/google/silifuzz.git && cd silifuzz
SILIFUZZ_SRC_DIR=`pwd`
./install_build_dependencies.sh # Currently, works for the latest Ubuntu only.
bazel build -c opt @silifuzz//tools:{snap_corpus_tool,fuzz_filter_tool,snap_tool,silifuzz_platform_id,simple_fix_tool_main} \
@silifuzz//runner:reading_runner_main_nolibc \
@silifuzz//orchestrator:silifuzz_orchestrator_main
SILIFUZZ_BIN_DIR=`pwd`/bazel-bin
cd "${SILIFUZZ_BIN_DIR}"
HINWEIS: Sie können einen Docker-Container verwenden, um das Hostsystem nicht zu verschmutzen: docker run -it --tty --security-opt seccomp=unconfined --mount type=bind,source=${SILIFUZZ_SRC_DIR},target=/app ubuntu:noble /bin/bash -c "cd /app && ./install_build_dependencies.sh && bazel build ... && bazel test ..."
Für Bazel verwenden Sie die folgenden Befehle.
cd "${SILIFUZZ_SRC_DIR}"
COV_FLAGS_FILE="$(bazel info output_base)/external/fuzztest+/centipede/clang-flags.txt"
bazel build -c opt --copt=-UNDEBUG --dynamic_mode=off \
--per_file_copt=unicorn/.*@$(xargs < "${COV_FLAGS_FILE}" |sed -e 's/,/\\,/g' -e 's/ /,/g') @//proxies:unicorn_x86_64
bazel build -c opt @fuzztest//centipede:centipede
mkdir -p /tmp/wd
# Fuzz the Unicorn proxy under Centipede 1000 times with parallelism of 30.
"${SILIFUZZ_BIN_DIR}/external/fuzztest+/centipede/centipede" \
--binary="${SILIFUZZ_BIN_DIR}/proxies/unicorn_x86_64" \
--workdir=/tmp/wd \
-j=30 --num_runs=1000
HINWEIS: Siehe Centipede-Dokumentation zur effizienten Ausführung der Fuzzing-Engine.
Dieses Hilfswerkzeug prüft, ob die Maschine, auf der Sie arbeiten, unterstützt wird.
$ ${SILIFUZZ_BIN_DIR}/tools/silifuzz_platform_id --short
intel-skylake
HINWEIS: Die CPU-Erkennungslogik von SiliFuzz berücksichtigt bestimmte Desktop-Varianten ansonsten unterstützter CPUs nicht. In solchen Fällen meldet das Werkzeug „Unsupported platform“.
Der fuzz_filter_tool wandelt rohe Instruktionen in Snap-kompatible Snapshots um. Er gibt 0 zurück, wenn die Umwandlung möglich ist, andernfalls 1. Diese Schnittstelle ist kompatibel mit Centipedes input_filter
fuzz_filter_tool raw_input_sequence
Die Datei raw_input_sequence enthält rohe Instruktionen, die mit InstructionsToSnapshot in das Snapshot-Format umgewandelt werden.
Beispielverwendung:
# INC EAX
echo -en '\xFF\xC0' > /tmp/inc_eax && ./tools/fuzz_filter_tool /tmp/inc_eax
echo $?
0
snap_tool untersucht und manipuliert binäre Snapshot-Protos. Es kann optional rohe Instruktionen laden und in einen Snapshot umwandeln.
echo -en '\xFF\xC0' > /tmp/inc_eax
./tools/snap_tool --raw print /tmp/inc_eax
Metadata:
Id: inc_eax
Architecture: x86_64 Linux
Completeness: complete
Registers:
gregs (non-0 only)
rax = 0x20000000
....
Das Simple-Fix-Tool übernimmt Fuzzing-Ergebnisse von Centipede, wandelt rohe Instruktionen in Snapshots ohne Endzustände um, fügt den Snapshots Endzustände hinzu und verpackt die Snapshots schließlich in einen in Shards aufgeteilten, relocatable Snap-Corpus.
Derzeit läuft dies als nicht neu startbarer Prozess auf einem einzelnen Host, und alles wird im Speicher gehalten, sodass die Größe des verarbeitbaren Corpus durch den verfügbaren Speicher des Hosts begrenzt ist. Da die Endzustände auf dem Host erzeugt werden, ist der resultierende Corpus nur für eine einzige Architektur ausgelegt.
Experimentell: Hash-Tests sind randomisierte, strukturierte Tests, die Entropie in zufällig erzeugte Instruktionen einbringen und die resultierenden Ausgaben so effizient wie möglich erfassen. Dieser Ansatz basiert auf der Beobachtung, dass ein nicht unerheblicher Prozentsatz von Defekten erkannt werden kann, indem die richtige Instruktion mit der richtigen Eingabe aufgerufen wird. Hash-Tests zielen gezielt auf diese einfache Defektklasse ab, um einen experimentellen Vergleichspunkt für SiliFuzz zu bieten. Derzeit wird nur x86_64 unterstützt.
Wenn Sie beispielsweise 30.000 Hash-Test-Snapshots mit Instruktionen, die von Skylake-Prozessoren unterstützt werden, im Verzeichnis /tmp/hashtest erzeugen möchten, können Sie diesen Befehl ausführen.
mkdir -p /tmp/hashtest && bazel run -c opt @silifuzz//fuzzer/hashtest:hashtest_generator -- --platform=intel-skylake -n 30000 --outdir /tmp/hashtest
Der Rest des Dokuments ist als Anleitung (How-to) organisiert, wobei jede Frage einen typischen Anwendungsfall beschreibt. Die Reihenfolge der Fragen entspricht der zunehmenden Komplexität der Aufgabe, die man bewältigen möchte. Jeder Schritt erfordert in der Regel entweder das Verständnis oder die Artefakte (manchmal beides), die im vorherigen Schritt gewonnen wurden.
HINWEIS: Das Dokument setzt eine x86_64-Host-/Ziel-CPU voraus. Die genaue Ausgabe kann je nach CPU-Hersteller/Stepping usw. und der Umgebung (z. B. Docker/KVM) variieren.
WARNUNG: Viele der folgenden Anweisungen führen beliebigen Binärcode mit den Rechten des aktuellen Benutzers aus. Das Tool versucht sein Bestes, den Code mit seccomp(2) zu sandboxen. Nutzung auf eigene Gefahr.
# INC EAX
$ echo -en '\xFF\xC0' > /tmp/inc_eax
$ ./tools/snap_tool --raw --out=/tmp/inc_eax.pb make /tmp/inc_eax
# CPUID
$ echo -en '\x0F\xA2' > /tmp/cpuid
$ ./tools/snap_tool --raw --out=/tmp/cpuid.pb make /tmp/cpuid
<error log omitted>
Could not load snapshot: INTERNAL: Tracing failed: Banned instruction: CPUID
HINWEIS: Um nicht-deterministische Ergebnisse zu vermeiden, schließen verschiedene Teile von SiliFuzz bestimmte Klassen von Instruktionen aus, z. B. CPUID oben.
$ ./tools/snap_tool print /tmp/inc_eax.pb
Metadata:
Id: inc_eax
Architecture: x86_64 Linux
Completeness: complete
Registers:
gregs (non-0 only):
rax = 0x20000000
rip = 0xeb85c12b000
<omitted>
End states (1):
Endpoint:
Instruction address: 0xeb85c12b002
Platforms:
intel-skylake
Registers (diff vs snapshot's initial values):
gregs (modified only):
rax = 0x20000001
rip = 0xeb85c12b002
<omitted>
Beachten Sie, dass der Endzustandswert des RAX-Registers 0x20000001 ist (0x20000000+1, was genau dem entspricht, was INC EAX tut). Beachten Sie außerdem, dass der RIP-Wert der ursprüngliche Wert +2 ist, also die Größe der INC EAX-Instruktion.
$ ./tools/snap_tool play /tmp/inc_eax.pb
Snapshot played successfully.
Hinweis: Sie müssen eine Zielplattform angeben, um einen Corpus zu erzeugen. In diesem Beispiel zielt der resultierende Corpus auf die Plattform, auf der er erzeugt wurde.
$ cd "${SILIFUZZ_BIN_DIR}"
$ PLATFORM_ID=$(./tools/silifuzz_platform_id --short)
$ ./tools/snap_tool generate_corpus /tmp/inc_eax.pb \
--target_platform="${PLATFORM_ID}" > /tmp/inc_eax.corpus
# Will play the same "INC EAX" snapshot 1M times
$ ./runner/reading_runner_main_nolibc /tmp/inc_eax.corpus
Sie können den Prozess mit gdb untersuchen:
$ gdb ./runner/reading_runner_main_nolibc
(gdb) b RestoreUContextNoSyscalls
(gdb) run /tmp/inc_eax.corpus
Starting program: .../reading_runner_main_nolibc /tmp/inc_eax.corpus
Breakpoint 1, 0x0000456700010598 in RestoreUContextNoSyscalls ()
(gdb) x/i 0xeb85c12b000 # same as the rip value produced by snap_tool print above
0xeb85c12b000: inc %eax
HINWEIS: Dieser Schritt setzt den zuvor beschriebenen Schritt „Fuzzing des Unicorn-Ziels“ voraus.
Konvertieren Sie die Fuzzing-Ergebnisse corpus.* in einen aus 10 Shards bestehenden, ausführbaren Corpus für die aktuelle Architektur.
cd "${SILIFUZZ_BIN_DIR}"
"${SILIFUZZ_BIN_DIR}/tools/simple_fix_tool_main" \
--num_output_shards=10 \
--output_path_prefix=/tmp/wd/runnable-corpus \
--runner="${SILIFUZZ_BIN_DIR}/runner/reading_runner_main_nolibc" \
/tmp/wd/corpus.*
Die Corpus-Shards befinden sich unter /tmp/wd/runnable-corpus.*
$ ./tools/snap_corpus_tool list_snaps /tmp/inc_eax.corpus
...
I0000 00:00:1661887744.019079 4074672 snap_corpus_tool.cc:155] inc_eax
HINWEIS: Dies ist derzeit ein sehr einfaches Werkzeug, das nur wenige Befehle bietet.
# Will play the same "INC EAX" snapshot on CPU#1 10k times.
$ ./runner/reading_runner_main_nolibc \
--cpu=1 --num_iterations=10000 /tmp/inc_eax.corpus
Der Orchestrator durchläuft alle Shards, die in der Datei aufgelistet sind, die über das Argument --shard_list_file übergeben wird.
$ ls -1 /tmp/wd/runnable-corpus.* > /tmp/wd/shard_list
$ echo 'version: "local_corpus"' > /tmp/wd/corpus_metadata
# Will repeatedly run the corpus on all available CPU cores for 30s using
# /tmp/wd/runnable-corpus.* selected randomly.
$ ${SILIFUZZ_BIN_DIR}/orchestrator/silifuzz_orchestrator_main --duration=30s \
--runner=${SILIFUZZ_BIN_DIR}/runner/reading_runner_main_nolibc \
--shard_list_file=/tmp/wd/shard_list \
--corpus_metadata_file=/tmp/wd/corpus_metadata
HINWEIS: Der Orchestrator kann auch XZ-komprimierte Corpus-Shards aus Dateien laden, die auf .xz enden.