On Tue, May 19, 2026 at 11:31 PM Ahmad Hasan <[email protected]> wrote: > Thank you for your questions. I'll address each one: > > == 1. Threat Model == > > The target scenario is a same-machine attacker > in multi-tenant/cloud environments where two > processes share physical L3 cache. > > Example: a cryptographic service and a malicious > process running on the same host. The attacker > uses Flush+Reload to measure cache access timing > after every encryption operation — no physical > access required. > > This is documented with real measurements: > - Without TID: 78 cycles (Cache HIT — key pattern visible) > - With TID v2.0: 286 cycles (Cache MISS — attack defeated)
So you're assuming that the cryptographic code leaks secrets through a cache-based side channel? That would be a vulnerability in the crypto code. > == 2. Why Kernel Module and not userspace? == > > You are correct that CLFLUSHOPT does not require > Ring 0. However, userspace execution can be > interrupted by a Context Switch, which expands > the timing window from 372ns to 36,640ns — > making the attack significantly easier. Why does it matter how many hundreds of nanoseconds it takes to wipe the data from memory? You can also have a context switch directly before you enter your cache-wiping syscall, or in the middle of a crypto operation. > == 3. Why not add this directly to libraries? == > > No major security library implements CLFLUSHOPT > after wiping — not OpenSSL, not libsodium, not > glibc, not memzero_explicit. This gap has existed > since Flush+Reload was published in 2014. I don't think that's a gap, because the standard approach to mitigating cache-based side channels such as FLUSH+RELOAD is to not access memory at secret-dependent indices in the first place.
