Store-to-Leak Forwarding: There and Back Again
summary
Demonstrates that correct store-to-load forwarding still leaks whether a virtual page is mapped and recently used, producing practical primitives called fetch and bounce and a Meltdown-like variant echelod that encode kernel presence into cache/TLB timing; implemented with TSX or segfault handlers, runs in userland, works in SGX and JavaScript, and on an i9 with TSX measures a page in ~29 microseconds with F‑score 1. Proposes FLARE—map all candidate kernel slots, unify page sizes, split executable/non‑exec ranges—to eliminate the timing differences.
AI-written summary · about
chapters (20)
- 0:00Start
- 0:39Motivation
- 1:22In-Order Execution
- 2:24Reality: Out-of-Order Execution, Transient Execution
- 3:29Side Effects of Transient Execution
- 4:19Measuring Cache State
- 5:13Memory Subsystem
- 8:36Store Buffer Match Logic
- 11:26Virtual Addresses
- 15:37Repeating Data Bounce
- 17:47Observing Kernel Activity
- 21:49Spectre
- 25:00Speculative Fetch+Bounce
- 26:42Reverse-Engineering Meltdown Hardware Mitigations
- 27:13Verifying the Hypothesis
- 30:20Performance of EchoLoad
- 31:28Commonalities of Previous Microarchitectural Attacks
- 32:29Fake Load Address REsponse (FLARE)
- 34:51Proof-of-Concept
- 35:10Conclusion
related talks
41mUsing Microarchitectural Design to Break KASLR and More
27mTranslation Leak-aside Buffer: Defeating Cache Side-channel Protections
25mThe Memory of a Meltdown
43mUsing Undocumented CPU Behavior to See Into Kernel Mode and Break KASLR in the Process
01h 01mTutorial: Side-Channel Attacks and Transient Execution Vulnerab...
23mMeltdown: Reading Kernel Memory from User Space
34mSTACKLEAK: A Long Way to the Linux Kernel Mainline
35mSingle Instruction Multiple Data Leaks in Cutting-edge CPUs, AKA Downfall