[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAmtCfMHqdWbYh-Hc5sGbOhXSM-aCA9G0-s64G8FTM+rGEV5RA@mail.gmail.com>
Date: Wed, 20 May 2026 00:31:45 +0300
From: Ahmad Hasan <ahmaaaaadbntaaaaa@...il.com>
To: Jann Horn <jannh@...gle.com>
Cc: linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
linux-hardening@...r.kernel.org, kernel-hardening@...ts.openwall.com,
linux-crypto@...r.kernel.org, linux-mm@...ck.org, linux-api@...r.kernel.org,
linux-kselftest@...r.kernel.org
Subject: Re: [RFC] TID v2.0: kernel module for cache-line zeroization against
Flush+Reload (CLFLUSHOPT + LFENCE + REP STOSQ)
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)
The 78-cycle result proves the data remains in
cache after memzero. If cache eviction happened
automatically, we would always see 286 cycles.
Full threat model: Section 2.1 of the paper.
Timing analysis: Section 5.2.
== 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.
The Kernel Module guarantees:
- Non-preemption during the PROTECT+ZERO sequence
- Atomic execution across wipe + flush + barrier
- Reliable page locking via pin_user_pages_fast
This is documented in Section 5.2 and Section 5.4.
A userspace library implementation is a valid
alternative and is noted as future work — the
goal is eventually integrating CLFLUSHOPT
directly into libsodium and OpenSSL.
== 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.
TID is a proof of concept that demonstrates the
PROTECT+ZERO protocol works. The next step is
proposing integration into existing libraries.
Full comparison table: Section 2.3 of the paper.
== References ==
DOI: https://doi.org/10.5281/zenodo.17585929
GitHub: https://github.com/ahmaaaaadbntaaaaa-byte/
TID-The-Instant-Destroyer
Sections 2.1, 2.3, 5.2, 5.4 address your points
in detail.
Regards,
Ahmad Qasim Mohammad Hassan
Independent Hardware Security Researcher
ORCID: 0009-0001-4360-0802
في الثلاثاء، ١٩ مايو ٢٠٢٦, ٧:٤٧ م Jann Horn <jannh@...gle.com> كتب:
> On Mon, May 18, 2026 at 11:47 PM Ahmed Hassan
> <ahmaaaaadbntaaaaa@...il.com> 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.)
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
