Artifact – ExfilState: Automated Discovery of Timer-Free Cache Side Channels on ARM CPUs

This repository contains the artifact for the paper "ExfilState: Automated Discovery of Timer-Free Cache Side Channels on ARM CPUs". It is archived on Zenodo, where you can find the zip files for experiments E2 and E3.

Note

A standalone and updated version of the ExfilState fuzzer is available here.

Note

This repository relies on Git LFS to handle large files. Please install it before cloning the repository. If you cloned without having LFS installed or have other problems with LFS files run: git lfs install && git lfs pull.

Abstract

This artifact accompanies our paper "ExfilState: Automated Discovery of Timer-Free Cache Side Channels on ARM CPUs". It includes ExfilState, evaluation scripts, and proof-of-concepts demonstrating newly discovered architectural side channels across ARM microarchitectures. We provide analyses of these side channels and case studies such as AES T-table leakage. The artifact enables researchers to uncover new architectural side channels on ARM CPUs, to reproduce our findings, and to use the discovered side channels in other attacks.

Structure

The repository is organized into the following directories:

• exfilstate: The fuzzing framework (Sections 3-4).
• framework_evaluation: Evaluation of the framework, including results for our large-scale fuzzing run and ablation study (Section 5).
• side_channels: Proof-of-concepts and evaluation of discovered side channels (Section 6).
• case_studies: Case studies demonstrating impact, e.g., AES T-table leakage and Spectral (Section 7).

Hardware Requirements

The artifact provides proof-of-concepts and case studies for a Cortex-A72 available in, e.g., a Raspberry Pi 4.

Set Up

The entire artifact uses Nix to easily provide the required packages for the various parts. Nix is a declarative package manager, i.e., needed packages can be specified in a file, locked via a lock file and then loaded reproducibly. Each directory contains a flake.nix or shell.nix, specifying the packages and environment. Nix can be installed on a large range of Linux distributions. If your distribution is not supported please fall back to the provided Docker container or a Docker container running, e.g., Ubuntu 24.04.

Native Installation (in Container or Native System)

1. Please install Nix. We recommend the multi-user installation if root privileges are available.

2. The artifacts further use an experimental Nix feature called Flakes. This feature needs to be enabled by running the following command:

   mkdir -p ~/.config/nix && echo 'experimental-features = nix-command flakes' > ~/.config/nix/nix.conf

3. Quickly verify that Nix Flakes work by running:

   nix run 'nixpkgs#hello'

   This should print "Hello, world!".

4. For automatically loading the environment for each directory the artifact uses direnv. With Nix already installed it can be simply installed by running:

   nix profile add 'nixpkgs#direnv'

   For other package managers refer to this page.

5. Please also setup your shell to automatically load the environment as specified here.

Docker Environment

If unfamiliar with Nix, you can use the provided Docker container.

1. Build the container with:

   docker build . -t exfilstate-artifact

   This should finish rather quickly, but depending on the internet connection can take up to 10 minutes.

2. Create a container (change the artifact mountpoint if needed):

   docker run -dit -v .:/mnt --name exfilstate-artifact exfilstate-artifact

3. Attach to container with:

   docker exec -w /mnt -it exfilstate-artifact bash

Quick Start & Basic Tests

For each directory, the provided environment has to be trusted first by running:

direnv allow

Run this now for the top-level directory.

Please run this command in the top-level (this) directory and verify that CC is correctly set to a static aarch64 (cross) compiler:

echo $CC # expected: aarch64-unknown-linux-musl-gcc

We provide a helper script direnv-allow-all.sh which finds, trusts and builds each environment. We recommend to run this once and wait for it to finish. Note that this can take up to 3 hours, as all environments including cross compilers are build. After running the command, the environments are however cached.

You can now proceed to the following experiments. If you find any runtime or compilation errors it is likely that the Nix & direnv setup is somehow corrupted, as the artifact should provide all packages needed to run the experiments.

Experiments

The following roadmap describes the artifact evaluation. Each experiment is based on instructions in the respective subdirectory README. We summarize the claim, high-level execution, expected result, and machine.

E1: Fuzzing Campaign with ExfilState (45 person-minutes)

Claim: The fuzzer discovers architectural side channels on ARM CPUs.

Execution: Build and run the fuzzer as described in exfilstate/README.md. Build and run a reproducer (yaml file) to verify that it provides an architectural cache side channel on the device.

Expected Result: Reproducers are logged and reproduce on the device.

Machine: Raspberry Pi 4 (Cortex-A72).

E2: Large-Scale Side-Channel Discovery Results (60 person-minutes)

Claim: ExfilState efficiently discovers and correctly clusters architectural side channels.

Execution: Process the provided campaign results following framework_evaluation/side_channel_discovery/README.md. Run clustering, categorization, complexity and time to discovery analyses.

Expected Result: The >100k reproducers are efficiently clustered into 32 classes. The categorization stage correctly assigns the reproducers to one of the 5 discovered side channels. Complexity and time to discovery of the discovered side channels is relatively low.

Machine: Any (preferably a fast and highly parallel machine).

E3: Ablation Study (30 person-minutes)

Claim: The parameter selection of sequence length 8 and 2 registers gives the best results.

Execution: Extract and process results as in framework_evaluation/ablation_study/README.md. Plot Figure 3.

Expected Result: The plots show optimal discovery performance at sequence length 8 and 2 registers.

Machine: Any (preferably a fast machine).

E4: LX-SX PoC (15 person-minutes)

Claim: LX-SX side channel accurately leaks cache state.

Execution: Build and run the proof-of-concept as described in side_channels/pocs/lx_sx/a72/README.md.

Expected Result: Clear distinction between cache hits and misses on the Cortex-A72.

Machine: Raspberry Pi 4 (Cortex-A72).

E5: Side-Channel Performance (15 person-minutes)

Claim: The discovered side channels perform well, evaluated in a covert channel setting.

Execution: Build and run the benchmark described in side_channels/covert_channel/README.md and run on Cortex-A72.

Expected Result: High covert channel speed with low (< 0.1%) error rate.

Machine: Raspberry Pi 4 (Cortex-A72).

E6: Case Studies — AES T-table Attack (30 person-minutes)

Claim: The discovered side channels enable AES T-table key recovery.

Execution: Compile and run the AES T-table case study in case_studies/aes_t_table/README.md on Cortex-A72.

Expected Result: Correct diagonal matrix and successful key recovery with architectural side channel.

Machine: Raspberry Pi 4 (Cortex-A72).

E7: Case Studies — AES T-table Mitigation (30 person-minutes)

Claim: The discovered side channels can be effectively used to detect attacks on AES T-table.

Execution: Mount the mitigation as specified in case_studies/aes_t_table_mitigation/README.md on Cortex-A72.

Expected Result: High precision and recall when detecting attacks using the architectural side channel.

Machine: Raspberry Pi 4 (Cortex-A72).

E8: Case Studies — Spectral Case Study on Cortex-A72 (30 person-minutes)

Claim: Fast Spectral (architectural Spectre) leakage on Cortex-A72.

Execution: Compile and benchmark Spectral as in case_studies/spectral/README.md on Cortex-A72.

Expected Result: Stable Spectral leakage of >5 kB/s.

Machine: Raspberry Pi 4 (Cortex-A72).