CacheWarp: A new software fault attack on AMD SEV-ES and SEV-SNP

I work at AWS on these systems. We do fund research on Graviton. But our main approach to "Confidential Computing" has always been very different and based on the Nitro system. We run our virtualization on dedicated Nitro cards, with their own CPUs and memory, that are separate from the hardware running customer's EC2 instances. The Nitro system is hermetic and doesn't grant us access to a customer's memory or operations, and the simple design and interface is there to minimize the surface area for any potential issues. (We also put all this in our terms of service).

All customers on Nitro get that enhanced confidentiality between their instance and us as a cloud provider, but for customers who want to run workloads that are confidential from themselves, we do also offer AMD SEV based instances as well as our own Nitro Enclaves product.

Frankly, this whole exercise of "don't trust the cloud host" is pretty dumb. Flaws in chipset vendor products and new avenues of fuckery will continue to to be found.

Expecting that you can trust a computer you've never even seen, let alone one you *know* is a VM with a whole other untrusted OS under it, is a fool's errand.

If you need this level of trust, you should be on-prem. No excuses.

You mean like every other OS in production?

More than defeatist, its relativist. Minimizing the trusted computing base is an important tool for higher security guarantees. It's obvious that whatever the size of your TCB, a bug is a bug. In any case, i believe TDR's rant was specifically about x86 and not about virtualization or any kind of low level isolation per se.

The newest Intel CVE seems tied to some legacy handling of duplicate prefixes, where it usually ignores duplicate prefixes since they were used to pad memory registers sometimes. A newer feature added onto x86 is the underlying problem (FSRM), but it's mishandling those "battle tested" instructions/improperly reading them.

So really, it's a combination of things that led to this CVE, and the longer we stay on an old platform the more strange combinations we might find!

Actually this particular bug comes directly from the obsolete instruction "invd", which was introduced in Intel 80486, in 1989.

This instruction should have been disabled when virtualization is used and when it is desired that the virtual machines must be protected even against the hypervisor, not only against each other. Even better would be if this instruction would be removed completely. Because it is a privileged instruction, its removal would not affect any user applications.

This is one of the very rare cases when Intel has done the right thing (disabling INVD when it could be used by an attacker), while AMD has not thought about it.

Fortunately, it seems that AMD can fix this oversight with a microcode update.

I'm just thinking about Windows. They are trying to do ARM again, but x86/64 is where they have stayed for compatibility reasons. At a certain point old software won't run on new Windows anyway, so it won't need hardware compatibility with older instructions to facilitate that.

Eventually something will have to change, and is it less work for Intel to shift to ARM than to strip x86?

> an instruction set that strips everything but the necessary instructions sounds a lot like ARM

Have you, by any chance, looked into the contemporary ARM instruction set? Just the list of base instructions for A-profile with 1-2 instructions per line takes 14 pages. And then there are SIMD&FP Instructions, SVE Instructions, SME Instructions. Oh, and also M-profile, and Thumb / Thumb-2 instructions encodings, and more.

A small glimpse could be made here: https://developer.arm.com/documentation/ddi0602/2023-09/?lan...

This does make sense, since they can schedule CVE announcements.