TID v2.0: kernel module for cache-line zeroization against Flush+Reload (CLFLUSHOPT + LFENCE + REP STOSQ)

--000000000000f5a75806521fb7ab
Content-Type: text/plain; charset="UTF-8"

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.


== Approach: PROTECT+ZERO Protocol ==

TID combines three instructions in a single kernel module:

Phase 1 - PROTECT (before data use):
  LFENCE <- close speculative execution window
  MFENCE <- ensure all prior writes are complete

Phase 2 - ZERO (after data use):
  LFENCE <- close speculation window
  REP STOSQ <- compiler-resistant wipe
  CLFLUSHOPT <- evict all cache lines (L1/L2/L3)
  MFENCE <- ensure eviction is complete
  LFENCE <- close the far-side window

This follows directly the Intel Spectre Mitigation Guide (2018) and
AMD Speculative Execution Software Techniques (2018).


== Benchmark Results (AMD EPYC 9B14, Linux 6.14.11) ==

Without TID : attacker measures ~78 cycles (Cache HIT)
With TID v2 : attacker measures ~286 cycles (Cache MISS)
Ratio : 3.7x latency increase -- attack defeated

Physical lower bound confirmed:
  LFENCE (~40ns) + REP STOSQ (~50ns) + CLFLUSHOPT (~150ns)
  + MFENCE (~40ns) + LFENCE (~40ns) = ~320ns
  (measured: 290-372ns)


== What Distinguishes TID ==

No major security library implements CLFLUSHOPT post-wipe eviction.
TID is the only known kernel-module-level implementation of the
PROTECT+ZERO protocol.


== Known Limitations ==

- A 372ns window during data use remains (physical lower bound);
  v3.0 target via Intel CAT integration
- Requires same-machine attacker model (shared memory)
- Does not protect against cold-boot attacks
- Not a replacement for disk encryption


== Project Details ==

License : AGPL-3.0
Hardware : AMD EPYC 9B14 (Zen 4), x86_64
Kernel : Linux 6.14.11
DOI : https://doi.org/10.5281/zenodo.17585929
GitHub : https://github.com/ahmaaaaadbntaaaaa-byte/The-Instant-Destroyer

Comments and technical criticism are welcome.

Regards,
Ahmad Qasim Mohammad Hassan
Independent Hardware Security Researcher
ORCID: 0009-0001-4360-0802

--000000000000f5a75806521fb7ab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"rtl">Hi kernel developers,<div><br></div><div>I am sharing TID =
(The Instant Destroyer) v2.0, a Linux kernel module</div><div>written in C =
that addresses a specific gap in existing security</div><div>libraries: non=
e of them (libsodium, OpenSSL, glibc memzero_explicit)</div><div>flush CPU =
cache lines after memory zeroization.</div><div><br></div><div><br></div><d=
iv>=3D=3D Problem =3D=3D</div><div><br></div><div>Standard zeroization func=
tions (explicit_bzero, sodium_memzero,</div><div>OPENSSL_cleanse) prevent t=
he compiler from eliding the wipe, but do</div><div>not evict CPU cache lin=
es (L1/L2/L3). This leaves residual key</div><div>material measurable via F=
lush+Reload (Yarom &amp; Falkner, 2014) after</div><div>data use ends.</div=
><div><br></div><div><br></div><div>=3D=3D Approach: PROTECT+ZERO Protocol =
=3D=3D</div><div><br></div><div>TID combines three instructions in a single=
 kernel module:</div><div><br></div><div>Phase 1 - PROTECT (before data use=
):</div><div>=C2=A0 LFENCE     &lt;- close speculative execution window</di=
v><div>=C2=A0 MFENCE     &lt;- ensure all prior writes are complete</div><d=
iv><br></div><div>Phase 2 - ZERO (after data use):</div><div>=C2=A0 LFENCE =
    &lt;- close speculation window</div><div>=C2=A0 REP STOSQ  &lt;- compil=
er-resistant wipe</div><div>=C2=A0 CLFLUSHOPT &lt;- evict all cache lines (=
L1/L2/L3)</div><div>=C2=A0 MFENCE     &lt;- ensure eviction is complete</di=
v><div>=C2=A0 LFENCE     &lt;- close the far-side window</div><div><br></di=
v><div>This follows directly the Intel Spectre Mitigation Guide (2018) and<=
/div><div>AMD Speculative Execution Software Techniques (2018).</div><div><=
br></div><div><br></div><div>=3D=3D Benchmark Results (AMD EPYC 9B14, Linux=
 6.14.11) =3D=3D</div><div><br></div><div>Without TID : attacker measures ~=
78 cycles  (Cache HIT)</div><div>With TID v2 : attacker measures ~286 cycle=
s (Cache MISS)</div><div>Ratio       : 3.7x latency increase -- attack defe=
ated</div><div><br></div><div>Physical lower bound confirmed:</div><div>=C2=
=A0 LFENCE (~40ns) + REP STOSQ (~50ns) + CLFLUSHOPT (~150ns)</div><div>=C2=
=A0 + MFENCE (~40ns) + LFENCE (~40ns) =3D ~320ns</div><div>=C2=A0 (measured=
: 290-372ns)</div><div><br></div><div><br></div><div>=3D=3D What Distinguis=
hes TID =3D=3D</div><div><br></div><div>No major security library implement=
s CLFLUSHOPT post-wipe eviction.</div><div>TID is the only known kernel-mod=
ule-level implementation of the</div><div>PROTECT+ZERO protocol.</div><div>=
<br></div><div><br></div><div>=3D=3D Known Limitations =3D=3D</div><div><br=
></div><div>- A 372ns window during data use remains (physical lower bound)=
;</div><div>=C2=A0 v3.0 target via Intel CAT integration</div><div>- Requir=
es same-machine attacker model (shared memory)</div><div>- Does not protect=
 against cold-boot attacks</div><div>- Not a replacement for disk encryptio=
n</div><div><br></div><div><br></div><div>=3D=3D Project Details =3D=3D</di=
v><div><br></div><div>License  : AGPL-3.0</div><div>Hardware : AMD EPYC 9B1=
4 (Zen 4), x86_64</div><div>Kernel   : Linux 6.14.11</div><div>DOI      : <=
a href=3D"https://doi.org/10.5281/zenodo.17585929">https://doi.org/10.5281/=
zenodo.17585929</a></div><div>GitHub   : <a href=3D"https://github.com/ahma=
aaaadbntaaaaa-byte/The-Instant-Destroyer">https://github.com/ahmaaaaadbntaa=
aaa-byte/The-Instant-Destroyer</a></div><div><br></div><div>Comments and te=
chnical criticism are welcome.</div><div><br></div><div>Regards,</div><div>=
Ahmad Qasim Mohammad Hassan</div><div>Independent Hardware Security Researc=
her</div><div>ORCID: 0009-0001-4360-0802</div></div>

--000000000000f5a75806521fb7ab--