A relevant point Scientific excellence in AI research needs a parallel
technical track translating the EU AI Act's technical provisions into
verifiable requirements, grounded in peer-reviewed science rather than
general policy language
Article 5 — the absolute red line: eight prohibited practices, no exceptions
Articles 9–15 — mandatory requirements for high-risk systems: risk
management, data governance, documentation, record-keeping, transparency,
human oversight, accuracy
Article 50 — transparency toward the user: AI interaction notice,
watermarking
Article 53 — obligations of GPAI providers: documentation, copyright,
downstream information
Article 55 — GPAI with systemic risks: evaluation, adversarial testing,
incident reporting
Without that translation governance stays conceptual and never reaches an
implementable form
Available at https://lnkd.in/dKx7cW5R
Those who agree with me that solutions will remain mere marketing until
2030 if they aren't implemented according to the law won't establish
standards because there are variables in artificial intelligence systems.
Some talk about emotions some about the role of the CEO some about
infrastructure, and some about governance. You'll remain stuck in a
marketing cycle for years

في الأربعاء، ٢٠ مايو ٢٠٢٦, ٢:٠٠ ص Ahmad Hasan <[email protected]>
كتب:

> Thank you for your response.
>
> I want to clarify one point:
>
> TID does not address what happens during
> key usage. TID addresses what happens after:
>
> After any sensitive data (keys, passwords,
> tokens) is used and memory is wiped —
> the residual data still exists in CPU cache
> (L1/L2/L3). This is what TID eliminates.
>
> This is a different problem from what you
> are describing.
>
> The full threat model, attack simulation,
> and benchmark results are documented in
> the research paper and repository:
>
> DOI: https://doi.org/10.5281/zenodo.17585929
> GitHub:
> https://github.com/ahmaaaaadbntaaaaa-byte/TID-The-Instant-Destroyer
>
> I welcome continuing this discussion after
> reviewing the research.
>
> Regards,
> Ahmad Qasim Mohammad Hassan
> ORCID: 0009-0001-4360-0802
>
> في الأربعاء، ٢٠ مايو ٢٠٢٦, ١٢:٤٢ ص Jann Horn <[email protected]> كتب:
>
>> 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.
>>
>