google/silifuzzFuzza implementações de CPU gerando entradas de teste a partir de proxies de software e, em seguida, executa-as em hardware real para detectar defeitos e errata de microarquitetura.
O SiliFuzz é um sistema que encontra defeitos em CPUs por meio de fuzzing de proxies de software, como simuladores de CPU ou desmontadores, e então executa as entradas de teste acumuladas (conhecidas como corpus) em CPUs reais em grande escala. O SiliFuzz é um trabalho em andamento; consulte o artigo para obter detalhes.
Fuzzing é uma técnica de testar um alvo (um aplicativo ou uma API) com um grande número de entradas de teste geradas em tempo real. O objetivo é tornar essas entradas tão interessantes e diversas quanto possível para acionar casos extremos. Em outras palavras, o fuzzing visa maximizar a cobertura de código combinada. Cobertura de código pode ter diferentes significados, por exemplo, quais blocos básicos são executados ou quais caminhos são percorridos no programa.
Para os propósitos do SiliFuzz, um proxy é qualquer sistema de software ou hardware que se comporte de maneira semelhante a alguns aspectos da CPU alvo. Por exemplo, um emulador de CPU ou um desmontador. Um proxy é necessário quando não podemos coletar diretamente informações de cobertura do alvo.
Ao aplicar técnicas de fuzzing a um proxy, podemos gerar uma série de entradas de teste (corpus) que produzem comportamento interessante no proxy. Nossa suposição subjacente é que isso se traduz em um comportamento igualmente interessante no alvo. Leia mais na .
Uma coleção de entradas usadas para testar o alvo é conhecida como corpus.
Um corpus razoavelmente grande contém milhões de entradas e geralmente é dividido em vários blocos não sobrepostos chamados shards.
Um snapshot do SiliFuzz descreve uma sequência curta de instruções de CPU mais um estado inicial dos registradores e da memória da CPU para executar essa sequência de forma determinística. Um snapshot típico contém menos de 100 bytes de código e é executado em microssegundos, mas pode ser arbitrariamente grande. Os snapshots são armazenados como buffers de protocolo silifuzz.proto.Snapshot.
Os snapshots são tipicamente criados a partir das entradas geradas por um mecanismo de fuzzing. Para fins de teste de CPU, essas entradas são filtradas para eliminar todos os snapshots não determinísticos. Leia mais na documentação.
Um estado final descreve o conteúdo dos registradores e da memória que se espera que exista ao final da execução de um Snapshot. Se o snapshot for executado de forma diferente em diferentes microarquiteturas de CPU, ele terá vários estados finais esperados.
Um Snap é uma representação em memória de um Snapshot que pode ser facilmente carregado e executado pelo Runner. Os Snaps são tipicamente carregados do disco por um reading runner. O formato em disco do Snap é essencialmente o mesmo que o formato em memória, exceto que os ponteiros nativos são substituídos por offsets. Consulte este cabeçalho para obter detalhes. Esse formato é frequentemente chamado de relocatable. Cada Snap contém exatamente um estado final esperado, ou seja, os Snaps são específicos da microarquitetura. Leia mais na documentação.
Runner é um binário para testar um único núcleo de CPU. Um runner consome um shard de corpus, executa repetidamente Snaps aleatórios nele e verifica se o estado final esperado é alcançado. O Runner é um processo de thread única.
O orquestrador é um processo que controla vários runners. Em uma configuração típica, o orquestrador executará continuamente um runner por núcleo lógico de CPU e acumulará e reportará quaisquer falhas produzidas pelos processos runners individuais.
Consulte este arquivo para obter a lista de microarquiteturas suportadas.
O SiliFuzz é executado em sistemas Linux x86_64 e aarch64. Foi testado com versões 5.x e 6.x do kernel Linux. Não há garantia de compatibilidade com versões mais antigas do kernel. O ABI vsyscall legado deve ser desativado para evitar falsos positivos.
Uma lista não exaustiva de bugs e defeitos que o SiliFuzz encontrou.
Um bug lógico é um comportamento inválido da CPU inerente a uma microarquitetura ou stepping específico de CPU. O SiliFuzz identificou os seguintes bugs:
Um defeito (elétrico) é um comportamento inválido da CPU que ocorre apenas em um ou vários chips. O SiliFuzz encontrou os seguintes defeitos que descrevemos no artigo:
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}"
NOTA: Você pode usar um contêiner Docker para evitar poluir o sistema host: 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 ..."
Para Bazel, use os seguintes comandos.
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
NOTA: Consulte a documentação do Centipede sobre como executar o mecanismo de fuzzing com eficiência.
Esta ferramenta auxiliar serve para verificar se a máquina em que você está executando é suportada.
$ ${SILIFUZZ_BIN_DIR}/tools/silifuzz_platform_id --short
intel-skylake
NOTA: A lógica de detecção de CPU do SiliFuzz não leva em conta certas variantes desktop de CPUs que, de outra forma, são suportadas. A ferramenta reportará "Unsupported platform" nesses casos.
O fuzz_filter_tool converte instruções brutas em Snapshots compatíveis com Snap. Ele retorna 0 quando a conversão é possível e 1 caso contrário. Esta interface é compatível com o input_filter do Centipede.
fuzz_filter_tool raw_input_sequence
O arquivo raw_input_sequence contém instruções brutas que serão convertidas para o formato Snapshot usando InstructionsToSnapshot.
Exemplo de uso:
# INC EAX
echo -en '\xFF\xC0' > /tmp/inc_eax && ./tools/fuzz_filter_tool /tmp/inc_eax
echo $?
0
O snap_tool examina e manipula protos binários de Snapshot. Ele pode opcionalmente carregar instruções brutas e convertê-las em Snapshot.
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
....
A ferramenta de correção simples pega os resultados de fuzzing do Centipede, converte instruções brutas em snapshots sem estados finais, adiciona estados finais aos snapshots e, por fim, empacota os snapshots em um corpus de snaps relocáveis em shards.
Atualmente, isso é executado como um processo não reiniciável em um único host e tudo é colocado na memória, portanto, o tamanho do corpus que pode ser manipulado é limitado pela memória disponível do host. Como os estados finais são gerados no host, o corpus resultante é de arquitetura única.
Experimental: os hash tests são testes estruturados aleatórios que injetam entropia em instruções geradas aleatoriamente e capturam as saídas resultantes da forma mais eficiente possível. Essa abordagem baseia-se na observação de que uma porcentagem não trivial de defeitos pode ser detectada ao chamar a instrução certa com a entrada certa. Os hash tests visam agressivamente essa classe simples de defeitos para fornecer um ponto experimental de comparação para o SiliFuzz. Atualmente, apenas x86_64 é suportado.
Se você quiser gerar, por exemplo, 30 mil snapshots de hash test contendo instruções suportadas pelos processadores Skylake no diretório /tmp/hashtest, você pode executar este comando.
mkdir -p /tmp/hashtest && bazel run -c opt @silifuzz//fuzzer/hashtest:hashtest_generator -- --platform=intel-skylake -n 30000 --outdir /tmp/hashtest
O restante do documento é organizado no estilo "How-to" (como fazer), com cada pergunta descrevendo um caso de uso típico. A progressão das perguntas representa a complexidade crescente da tarefa que se está tentando realizar. Cada etapa normalmente requer a compreensão ou os artefatos (às vezes ambos) obtidos na etapa anterior.
NOTA: Este documento pressupõe uma CPU host/alvo x86_64. A saída exata pode variar dependendo do fabricante/stepping/etc. da CPU e do ambiente (por exemplo, Docker/KVM).
AVISO: muitas das instruções abaixo executam código binário arbitrário com os privilégios do usuário em execução. A ferramenta faz o possível para isolar o código com seccomp(2). Use por sua conta e risco.
# 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
NOTA: Para evitar resultados não determinísticos, várias partes do SiliFuzz excluem certas classes de instruções, por exemplo, CPUID acima.
$ ./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>
Observe como o valor do estado final do registrador RAX é 0x20000001 (0x20000000+1, que é exatamente o que INC EAX faz). Observe também que o valor de RIP é o original +2, que é o tamanho da instrução INC EAX.
$ ./tools/snap_tool play /tmp/inc_eax.pb
Snapshot played successfully.
Nota: Você precisará especificar uma plataforma alvo para gerar um corpus. Neste exemplo, o corpus resultante tem como alvo a plataforma em que foi gerado.
$ 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
Você pode inspecionar o processo com gdb:
$ 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
NOTA: Esta etapa depende da etapa "fuzzing do alvo Unicorn" descrita anteriormente.
Converta o corpus.* de resultados de fuzzing em um corpus executável de 10 shards para a arquitetura atual.
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.*
Os shards do corpus estarão em /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
NOTA: Esta é uma ferramenta muito básica no momento, oferecendo apenas alguns comandos.
# 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
O orquestrador percorrerá todos os shards listados no arquivo passado no argumento --shard_list_file.
$ 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
NOTA: O orquestrador também pode carregar shards de corpus compactados com XZ de arquivos que terminam com .xz.