Wednesday, August 10th 2022
ÆPIC Leak is an Architectural CPU Bug Affecting 10th, 11th, and 12th Gen Intel Core Processors
The x86 CPU family has been vulnerable to many attacks in recent years. With the arrival of Spectre and Meltdown, we have seen side-channel attacks overtake both AMD and Intel designs. However, today we find out that researchers are capable of exploiting Intel's latest 10th, 11th, and 12th generation Core processors with a new CPU bug called ÆPIC Leak. Named after Advanced Programmable Interrupt Controller (APIC) that handles interrupt requests to regulate multiprocessing, the leak is claimeing to be the first "CPU bug able to architecturally disclose sensitive data." Researchers Pietro Borrello (Sapienza University of Rome), Andreas Kogler (Graz Institute of Technology), Martin Schwarzl (Graz), Moritz Lipp (Amazon Web Services), Daniel Gruss (Graz University of Technology), and Michael Schwarz (CISPA Helmholtz Center for Information Security) discovered this flaw in Intel processors.
Source:
ÆPIC Leak
ÆPIC Leak is the first CPU bug able to architecturally disclose sensitive data. It leverages a vulnerability in recent Intel CPUs to leak secrets from the processor itself: on most 10th, 11th and 12th generation Intel CPUs the APIC MMIO undefined range incorrectly returns stale data from the cache hierarchy. In contrast to transient execution attacks like Meltdown and Spectre, ÆPIC Leak is an architectural bug: the sensitive data gets directly disclosed without relying on any (noisy) side channel. ÆPIC Leak is like an uninitialized memory read in the CPU itself.You can try out the vulnerability as it's demonstration has been open-sourced by Graz Institute of Technology here. Currently, we have no information about the patch, but Intel has been made aware in December of 2021. Carrying a CVE tag CVE-2022-21233, the vulnerability can be avoided by disabling APIC MMIO or avoiding SGX.
A privileged attacker (Administrator or root) is required to access APIC MMIO. Thus, most systems are safe from ÆPIC Leak. However, systems relying on SGX to protect data from privileged attackers would be at risk, thus, have to be patched.

50 Comments on ÆPIC Leak is an Architectural CPU Bug Affecting 10th, 11th, and 12th Gen Intel Core Processors
These are all exploits that someone would have to use on a company network where they are trusted and have admin access.
This is not an SGX side channel, this is an APIC direct attack. However, on systems with SGX present root can be gained as a pivot point...
www.tomshardware.com/news/new-vulnerability-affects-all-amd-zen-cpus
In my opinion any piece regarding this should clearly state early on whether it requires physical access or can be exploited remotely, which is exactly the piece of information vast majority of us needs to know to evaluate how concerning it is.
Hope theres a firmware fix, that sounds even worse than the typical side channel attacks - and some of those had mitigtations that royally suckedGood thing TPU's article does, without a misleading title ;)
Right on the front page tooLike most of these risks it requires local admin access, the risk here is that SGX is bypassed and it's not a side channel attack - one disclosed for ryzen recently had to run the attack on a real core, to access data from the attached SMT thread - that's not just admin/root access but also screwing with running processes and locking them to specific cores and threads to work
Getting stale data seems risky, as an attack could potentially harvest a lot over time
For those willing to pay, security could be almost guaranteed. Companies wanting to "do it cheap", it would obviously not beI don't have the knowledge or tools to make my own. It's important to remember though - you don't know for sure the features any one chip supports unless you crack it open and get it under a microscope. And have someone very familiar with microprocessor design take a look at things. Even then, it's not 100%.
So you're saying 9th gen security is worse than 10th/11th/12th gen overall, but it doesn't have this specific vulnerability.
Do you know of a resource that lists all the vulnerabilities/defects of modern CPUs? Preferably back to the introduction of i3/i5/i7, but if one less complete exists I'm not opposed
I personally dislike Skylake (hence "garbage lake") and derivatives because they are affected by vulnerabilities that Haswell (and Broadwell, for laptops) are not (and they have that SGX crap that is used for DRM). If I were to buy an Intel computer, it would have to either have a *well CPU or Icelake+ (Sunny Cove+).
Can't SGX be disabled in the BIOS, and if you disable it, *lake processors behave the same as Haswell/Broadwell?
I don't like HT/SMT. I do work with audio sometimes and it can cause latency problems, especially when you're using real time monitoring of processed audio (eg singing with electric guitar when the "electric" part of "electric guitar" is being created in the PC from an input directly from the guitar). Every millisecond matters, especially to me because after a few, I'm thrown off.
My last two CPUs have been 9600K and 2500K - both non-HT. I think I read somewhere Intel will be including HT on all of their CPUs from now on, even their i3s. It'll probably stay that way as long as AMD is competitive at all levels (it was shortly after they began to be when Intel changed). In addition to the potential security problems brought by HT/SMT, it's nothing special: any performance brought to the table costs just as much power as if done on another core, and overclocks are reduced because of it (I especially like my single threaded performance). If non-HT/SMT CPUs are reintroduced in the next generations, I'll be sticking with them as long as they have enough cores. If not, I'll buy the amount I'd like, then disable HT/SMT, enjoying greater security, lower latency, and higher performance. in every program at all times except in rare occasions when loads are running which bring CPU usage up near 100%.
It was a big issue from 6th to 9?th gen intel
The HPET bug: What it is and what it isn't - overclockers.at
(Link is focused on games, but it also caused weird audio issues back in the day especially around the Vista era where networking and audio clashed, and networking taking priority would cause crackling and latency issues)
9th gen does have some minor partial hardware mitigations but it is nothing compared to Ice Lake (Sunny Cove) and derivatives AFAIK. Ultimately it is still just Skylake+*n, whereas Sunny Cove is a clean sheet design (yet still massively OoO and speculative, so it will always be vulnerable to some transient execution vulnerabilities I believe but I am not an expert, just a lay observer).
I explain in detail: The 9600T is said to have a base clock of 2.3GHz and a TDP of 35W, and the 9600K is said to have a base clock of 3.7GHz and TDP of 95W. If I'm remembering how things work correctly, and they still work the way they did when I learned things, this means: when at 100% utilization (probably non-AVX), the 9600T is able to run up to and including 2.3GHz without exceeding its TDP of 35W. The 9600K is able to run at 100% up to 3.7GHz using no more than 95W.
This means for heavily multithreaded tasks, the 9600T is 62% a 9600K.
Mr. T boosts to 3.9GHz, while K boosts to 4.6GHz.
This means when 9600T has a light workload, it's 85% of a 9600K.
To verify this, I would: first, take out my 9600K and put the 9600T in my motherboard. Then I'd enter the BIOS, load optimized defaults and boot into Windows. Then I'd load all CPU cores as much as I know how, sans (without) AVX. If it drops to 2.3GHz, we're done! If not, I'd download and install ThrottleStop, open it, and change the multiplier to whatever it is that makes 35 watts the value for CPU Package Power.
Then I'd pull out the 35 watt, stick in the 95 watt, and repeat the process outlined in Example.
If the T processor reaches a notably higher frequency than the K processor at 35W, then Intel is binning for higher performance at lower power.
If it doesn't, well then... they're not! lol
(personally I think 2.3GHz is a low base clock for 35W when 95W gives 3.7GHz. I'd think 35W would give you at the very least 2.6GHz- I'd expect 2.7-2.8GHz. Anyway... end of interruption). I'm pretty confident that Intel used to bin chips more extremely for low power consumption.
Another thing I find interesting - I've read mentioned casually from semi official sources, and heard this from people in conversation, that it's not always CPUs with lower VIDs which overclock best. You'd think so, but it's not so. My 2500K is a shining example of that. Its VID is 1.426V
1.426V
My 2500K's VID is higher than the voltage people say is safe to set the chip to lol. So this implies the 2500K is probably a bad example, right?
Wrong!
The thing is extremely stable at 4.9GHz with 1.43V. Rock solid stable. With 1.47V? it'll run almost everything you can think of at 5.2GHz. It can boot at 5.4GHz with 1.52V
AND REMEMBER: That VID is for the 2500K's maximum turbo boost frequency of 3.7GHz (3.3GHz base)