[RFC] TID v2.0: kernel modu le for cache-line zeroizatio n against Flush+Reload (CLFLUSHOPT + LFENCE + REP STOSQ)
Ahmed Hassan <[email protected]> Tue, 19 May 2026 00:39:59 +0300
| Newsgroups | com.openwall.lists.kernel-hardening,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
------CDKNMF2C75Z7NW35JVKMW1L7XC4WCL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi kernel developers, I am sharing TID (The Instant Destroyer) v2=2E0, 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=2E =3D=3D Problem =3D=3D 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)=2E This leaves residual key material measurable via Flush+Reload (Yarom & Falkner, 2014) after data use ends=2E =3D=3D Approach: PROTECT+ZERO Protocol =3D=3D 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)=2E =3D=3D Benchmark Results (AMD EPYC 9B14, Linux 6=2E14=2E11) =3D=3D Without TID : attacker measures ~78 cycles (Cache HIT) With TID v2 : attacker measures ~286 cycles (Cache MISS) Ratio : 3=2E7x latency increase -- attack defeated Physical lower bound confirmed: LFENCE (~40ns) + REP STOSQ (~50ns) + CLFLUSHOPT (~150ns) + MFENCE (~40ns) + LFENCE (~40ns) =3D ~320ns (measured: 290-372ns) =3D=3D What Distinguishes TID =3D=3D No major security library implements CLFLUSHOPT post-wipe eviction=2E TID is the only known kernel-module-level implementation of the PROTECT+ZERO protocol=2E =3D=3D Known Limitations =3D=3D - A 372ns window during data use remains (physical lower bound); v3=2E0 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 =3D=3D Project Details =3D=3D License : AGPL-3=2E0 Hardware : AMD EPYC 9B14 (Zen 4), x86_64 Kernel : Linux 6=2E14=2E11 DOI : https://doi=2Eorg/10=2E5281/zenodo=2E17585929 GitHub : https://github=2Ecom/ahmaaaaadbntaaaaa-byte/The-Instant-Destroy= er Comments and technical criticism are welcome=2E Regards, Ahmad Qasim Mohammad Hassan Independent Hardware Security Researcher ORCID: 0009-0001-4360-0802 Ahmed Hassan ------CDKNMF2C75Z7NW35JVKMW1L7XC4WCL Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><body><div dir=3D"auto">Hi kernel developers,<br><br>I= am sharing TID (The Instant Destroyer) v2=2E0, a Linux kernel module<br>wr= itten in C that addresses a specific gap in existing security<br>libraries:= none of them (libsodium, OpenSSL, glibc memzero_explicit)<br>flush CPU cac= he lines after memory zeroization=2E<br><br><br>=3D=3D Problem =3D=3D<br><b= r>Standard zeroization functions (explicit_bzero, sodium_memzero,<br>OPENSS= L_cleanse) prevent the compiler from eliding the wipe, but do<br>not evict = CPU cache lines (L1/L2/L3)=2E This leaves residual key<br>material measurab= le via Flush+Reload (Yarom & Falkner, 2014) after<br>data use ends=2E<b= r><br><br>=3D=3D Approach: PROTECT+ZERO Protocol =3D=3D<br><br>TID combines= three instructions in a single kernel module:<br><br>Phase 1 - PROTECT (be= fore data use):<br>=C2=A0 LFENCE=C2=A0=C2=A0=C2=A0=C2=A0 <- close specul= ative execution window<br>=C2=A0 MFENCE=C2=A0=C2=A0=C2=A0=C2=A0 <- ensur= e all prior writes are complete<br><br>Phase 2 - ZERO (after data use):<br>= =C2=A0 LFENCE=C2=A0=C2=A0=C2=A0=C2=A0 <- close speculation window<br>=C2= =A0 REP STOSQ=C2=A0 <- compiler-resistant wipe<br>=C2=A0 CLFLUSHOPT <= - evict all cache lines (L1/L2/L3)<br>=C2=A0 MFENCE=C2=A0=C2=A0=C2=A0=C2=A0= <- ensure eviction is complete<br>=C2=A0 LFENCE=C2=A0=C2=A0=C2=A0=C2=A0= <- close the far-side window<br><br>This follows directly the Intel Spe= ctre Mitigation Guide (2018) and<br>AMD Speculative Execution Software Tech= niques (2018)=2E<br><br><br>=3D=3D Benchmark Results (AMD EPYC 9B14, Linux = 6=2E14=2E11) =3D=3D<br><br>Without TID : attacker measures ~78 cycles=C2=A0= (Cache HIT)<br>With TID v2 : attacker measures ~286 cycles (Cache MISS)<br= >Ratio=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 3=2E7x latency increase -- att= ack defeated<br><br>Physical lower bound confirmed:<br>=C2=A0 LFENCE (~40ns= ) + REP STOSQ (~50ns) + CLFLUSHOPT (~150ns)<br>=C2=A0 + MFENCE (~40ns) + LF= ENCE (~40ns) =3D ~320ns<br>=C2=A0 (measured: 290-372ns)<br><br><br>=3D=3D W= hat Distinguishes TID =3D=3D<br><br>No major security library implements CL= FLUSHOPT post-wipe eviction=2E<br>TID is the only known kernel-module-level= implementation of the<br>PROTECT+ZERO protocol=2E<br><br><br>=3D=3D Known = Limitations =3D=3D<br><br>- A 372ns window during data use remains (physica= l lower bound);<br>=C2=A0 v3=2E0 target via Intel CAT integration<br>- Requ= ires same-machine attacker model (shared memory)<br>- Does not protect agai= nst cold-boot attacks<br>- Not a replacement for disk encryption<br><br><br= >=3D=3D Project Details =3D=3D<br><br>License=C2=A0 : AGPL-3=2E0<br>Hardwar= e : AMD EPYC 9B14 (Zen 4), x86_64<br>Kernel=C2=A0=C2=A0 : Linux 6=2E14=2E11= <br>DOI=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : <a href=3D"https://doi=2Eorg/10=2E5= 281/zenodo=2E17585929">https://doi=2Eorg/10=2E5281/zenodo=2E17585929</a><br= >GitHub=C2=A0=C2=A0 : <a href=3D"https://github=2Ecom/ahmaaaaadbntaaaaa-byt= e/The-Instant-Destroyer">https://github=2Ecom/ahmaaaaadbntaaaaa-byte/The-In= stant-Destroyer</a><br><br>Comments and technical criticism are welcome=2E<= br><br>Regards,<br>Ahmad Qasim Mohammad Hassan<br>Independent Hardware Secu= rity Researcher<br>ORCID: 0009-0001-4360-0802</div><div dir=3D"auto">Ahmed = Hassan </div></body></html> ------CDKNMF2C75Z7NW35JVKMW1L7XC4WCL--