On Mon, May 18, 2026 at 11:47 PM Ahmed Hassan <[email protected]> wrote: > > Hi kernel developers, > > I am sharing TID (The Instant Destroyer) v2.0, a Linux kernel module > written in C that addresses a specific gap in existing security > libraries: none of them (libsodium, OpenSSL, glibc memzero_explicit) > flush CPU cache lines after memory zeroization. > > > == Problem == > > Standard zeroization functions (explicit_bzero, sodium_memzero, > OPENSSL_cleanse) prevent the compiler from eliding the wipe, but do > not evict CPU cache lines (L1/L2/L3). This leaves residual key > material measurable via Flush+Reload (Yarom & Falkner, 2014) after > data use ends.
The thing you're talking about isn't really related to the Flush+Reload side channel attack, right? You're just talking about flushing cache lines. In what threat model would this be an issue? Normally, the goal of memory zeroing is to ensure that sensitive data is wiped before an attacker has a chance to physically pull out the RAM from a machine and plug it into another device that can reveal RAM contents, or before an attacker gains physical control of a locked device and can connect malicious peripherals to it, or such. So for this to be an actual security problem, the device would have to keep running in a sufficiently high power state that data caches are not discarded, and at the same time not perform enough memory accesses to cause this memory to be discarded... Assuming that this is an actual problem, why are you using a kernel module for this? At least on x86, CLFLUSH is unprivileged, so crypto libraries should be able to just use that directly. (There is the caveat of what happens when the kernel migrates pages or kills a process, but that's a larger problem.)
