ÆPIC Leak: Architecturally leaking uninitialized data from the microarchitecture [pdf]

The researchers built an informal taxonomy of all the CPU bugs we've seen in the past several years, using the CWE (bleh) as a reference. They noticed that anywhere they found a transient execution vulnerability (like a cache side channel) for a given CWE, they'd also find an architectural vulnerability (one exposed directly through the ISA) --- except for CWE-665, Improper Initialization, where their survey only identified transient attacks.

Working from a hypothesis that these kinds of attacks always come in pairs, they set out to find a CWE-665 vulnerability. They did something clever: they build a scanner. From one hardware thread, they kept known data patterns cached. From another, they used ring 0 code to systematically map and read the I/O address space; they could check all those reads for canary values from the first grooming process to detect leaks.

And they found one! The APIC interface (which routes interrupts) exposes successive 32 bit values (sometimes as 4-byte blocks of 8- or 32- byte data structure), which are always aligned on 128-bit boundaries; in other words, each 4-byte APIC value is embedded in a range of addresses 16-bytes wide. Reads past 4 bytes in those ranges are undefined. When their scanner read them, they caught canary values their grooming process wrote.

The theory here is that the cache system in these CPUs, which is organized around queues of buffers (to asynchronously handle loads from L2 cache, with line fill buffers, and the LL cache, with fill buffers in the "superqueue", is also used by the APIC system to satisfy reads: reads from the APIC are satisfied through the superqueue. Their grooming process is filling the whole superqueue up with canary values, and the APIC reads are failing to clear out the superqueue buffers when using them for APIC reads.

You can only launch this attack from ring 0 (you need access to physical memory). But that's enough to fatally break SGX, whose whole purpose is running compute on CPUs that don't trust their ring0.

Looks like it only works on Sunny Cove Intel.

When (if ever) could a reasonable person think "ok, now they must have got rid of all the vulnerabilities, time to trust this!" ?

...and then Intel will add another new architectural feature that will interact with SGX in some unforeseen way and break it yet again. SGX is surely just too fragile?

"AEPIC Leak is the first architectural CPU bug that leaks stale data from the microarchitecture without using a side channel. It architecturally leaks stale data incorrectly returned by reading undefined APIC-register ranges."

Our end-to-end attack extracts AES-NI, RSA, and even the Intel SGX attestation keysfrom enclaves within a few seconds.

Good. May all attempts at DRM and user-hostility die in the same manner. You're not the true owner if you can't inspect and modify the entire state of the machine. And fuck remote attestation too -- the true enemy of your freedom.

In fact it is quite strange that the attack skips Tiger Lake (Willow Cove), which changes almost nothing from Sunny Cove besides L2 and L3 cache sizes, but shows up again in Alder Lake (which has two types of cores: does the attack work on both efficiency and performance cores?)