Eviction Notice: Reviving and Advancing Page Cache Attacks

APPENDIX A ARTIFACT APPENDIX Page cache attacks have been thought to be mititgated or impractically slow since the mitigation of the Linux mincore syscall in 2019. In this paper, we not only revive practical attacks on the page cache, but also provide a systematic classification & understanding of primitives which interact with page cache. This understanding helps us advance page cache attacks, including speeding up previously known primitives by six orders of magnitude. This artifact demonstrates the four primitives which we describe in our paper – flush, reload, evict, and monitor –, two methods to overcome the read-ahead mechanism, syscalls determined to be reload mechanisms, covert channels, and proof-of-concept attacks. Our attacks are hardware-agnostic and primarily depend on the versions of the Linux kernel used. We recommend evaluating our attacks on kernel versions above 4.14, ideally above 6.5. In February 2025, one of the monitor mechanisms, the cachestat syscall was mitigated; patches have been rolled out across Linux distributions, and the exact patch number can be checked to determine when it was patched. However, cachestat is not strictly required for our evaluation, as we demonstrate our attacks using another monitor mechanism, preadv2 +RWF_NOWAIT, introduced in kernel 4.14 and still working. A. Description & Requirements 1) How to Access: Our Zenodo artifact is available at https://doi.org/10.5281/zenodo.17915256, made conveniently available at https://github.com/isec-tugraz/Eviction-Notice. 2) Hardware Dependencies: We tested all our attacks on x86 desktop / notebook CPUs. To keep evaluation times short, we suggest testing on Intel and AMD CPUs with 8 to 32 GB of RAM. 3) System Requirements: Linux kernel versions above 4.14 and ideally above 6.5. We developed and tested all our artifacts on Debian 13 and Debian-based Linux distributions (Ubuntu 22.04). Although our attacks should work on most Linux distributions, distribution-specific idiosyncrasies might make it challenging to mount attacks in the exact manner described in this artifact. One of the syscalls on which we rely as a monitor mechanism is cachestat. This syscall has been mitigated in February 2025, and no longer works in the crossuser threat model of our paper. Therefore, it may be necessary to downgrade the kernel for testing cachestat alone. However, we have another monitor mechanism, preadv2 + RWF_NOWAIT, which works with kernel versions above 4.14. Swapping should be switched off to keep evaluation time short. We suggest an ext4 filesystem and glibc version ≥2.34 is required. Finally, systems with /tmp/ mounted as tmpfs will not be able to carry out the specific implementation of this artifact. 4) Attack Requirements: Creating another user is required to completely evaluate our attacks in the cross-user threat model. To create another user requires root permissions. 5) Software Dependencies: None 6) Benchmarks: None 7) Security, Privacy, and Ethical Concerns: Our artifacts do not perform any malicious operations by design. The only evaluation which may be destructive is eviction-based evaluation: if aggressive values are chosen, it may cause the system to become unstable or even crash, requiring a forced restart. For eviction-based operations, we recommend closing applications, saving important data, and disabling swapping. All other operations are non-destructive. B. Artifact Installation & Configuration To configure a system in which cachestat (monitor mechanism) works in a cross-user threat model, please check the Debian Security Tracker for when different distributions patched it and revert to that patched kernel. Our monitor-based attacks are configured to use an alternative with preadv2 if setting up an unpatched kernel requires too much time. C. Experiment Workflow 1) Create a new user: sudo adduser testinguser 2) Download the zipped artifact file and unzip its contents to /path/. 3) Run the script: /path/helper-scripts/- create-testing-file.sh 4) Calibration: Compile code in /path/- calibration/ and run to compute three thresholds. 5) Set these thresholds across: •/path/primitives/Makefile •/path/covert-channels/- flush-reload/Makefile •/path/covert-channels/flush-flush/- Makefile •/path/attacks/docker/watcher/- watcher-flush_reload/Makefile 6) Primitives: Compile code in /path/primitives/ and evaluate all four primitives 7) Reload Mechanisms: Compile code in /path/- reload-mechanisms/ and evaluate all eleven syscalls & methods. 8) Covert Channels: Compile code in the three directories of /path/covert-channels and evaluate all three covert channels. 9) Attacks (1): Evaluate a Flush+Monitor attack to detect when a binary is run. 10) Attacks (2): Build two docker containers (using docker compose) and evaluate a Flush+Reload attack to detect when a binary is run cross-container. 11) Attacks (3): Using an apt version of Firefox, evaluate a Flush+Monitor attack to theoretically mount a website fingerprinting attack. D. Major Claims •(C1): Our work advances page cache attacks by systematically classifying flush, monitor, reload, and evict primitives. These four are outlined in Section III-A, IIIB, III-C, III-D and are proven by experiment (E2). 1 •(C2): In our work, we find two novel techniques to overcome a well-known limitation with reload: the readahead mechanism. This is proven by experiment (E2) and discussed in Section III-A: the backward-reading technique and readahead syscall. •(C3): Our work revives page cache attacks and improves state of the art by 6 orders of magnitude. Discussed in Section V-A, this is proven by experiment (E4) with a Flush+Monitor covert channel based on preadv2 and RWF_NOWAIT. E. Evaluation For each experiment, we provide in-depth instructions in the artifact’s singular README file. The structure of the README follows the experiment order in this appendix. 1) Experiment (E1): [Calibration] [10 human-minutes]: Determining timing thresholds [Preparation] The testing file should be created with create-testing-file.sh. In calibration/, execute make. [Execution] Run the three compiled binaries in build/, each with one argument: path to testing file. Run these binaries 5-10 times to gauge a good threshold. [Results] The binaries report FLUSH_THRESHOLD,READ_THRESHOLD, and READAHEAD_THRESHOLD. Note a threshold for each which appears most of the time (a rough number is fine). These will be set in the Makefiles in experiment (E2). 2) Experiment (E2): [Primitives] [50 human-minutes]: Validating primitives [Preparation] Set the determined thresholds from experiment (E1) in primitives/Makefile. Afterwards, run make and copy the build folder to /tmp/build-primitives. Ensure swapping is switched off. [Execution] As testinguser, execute the binaries in /tmp/- build-primitives to test flush, reload, monitor, and evict (detailed instructions in the README). Afterwards, test the read-ahead mechanism bypasses and eviction. Warning: Eviction may cause stability issues and possibly crashes. [Results] Flush and evict should be able to remove pages from the page cache, while reload brings it back into the page cache. Monitor reports the presence of pages in cache. monitor-cachestat may fail if the mitigation is in place. 3) Experiment (E3): [Reload Mechanisms] [10 humanminutes]: Validating 11 syscalls and methods as reload mechanisms. [Preparation] Run make in reload-mechanisms. [Execution] Run test-all-reload.sh. [Results] This experiment tests 11 syscalls and methods as reload mechanisms by flushing, reloading, and reloading again for each syscall and method. On average, there should be a notable timing difference between between [Flushed] and [After Reload]. 4) Experiment (E4): [Covert Channels] [20 humanminutes]: We demonstrate three out of five covert channels. Notably, Evict+Monitor and Evict+Reload are not provided to save time. Eviction is a challenging primitive on unknown systems, especially when run repeatedly. If eviction was made to work in experiment (E2), we claim that performing a reload or monitor preceded by an eviction is a rudimentary demonstration of an Evict-based covert channel. [Preparation] Set the determined thresholds from experiment (E1) in each of Makefiles in covert-channels/. Afterwards, run make in all three directories and copy the build folder to /tmp/covert-channels. Generate a synchronization and communication file. [Execution] One after the other, run each receiver as testinguser and the sender as the normal user. The Flush+Flush covert channel may be quite challenging for achieving a high accuracy as the threshold for flush is quite small. Nevertheless, we offer three suggestions in Flush+Flush section of the README to help achieving a higher accuracy. [Results] Each receiver of the covert channel reports a percentage of data correctly transmitted. Both the sender and receiver report time taken to transmit and receive. 5) Experiment (E5): [Attacks] [45 human-minutes]: [Preparation] Set the determined thresholds from experiment (E1) in the Makefile of attacks/docker/- watcher/watcher-flush_reload/Makefile. Run docker compose in the watcher and provoker directories. Install an apt version of Firefox. [Execution] First, run a flush and while-loop of monitor checking for the presence of htop in cache, and then run htop. Second, run the two docker containers. Start the program in watcher first watching ls, and execute ls in provoker. Finally, launch a Flush+Monitor loop on Firefox’s libxul.so, launch Firefox, and visit 5 websites. [Results] The first part reports htop’s presence in cache upon running htop. The second part reports a much lower timing when ls is executed cross-container. The third part reports a different range of values in libxul.so’s page count upon visiting different websites. 2