6 ms·

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

96 points by g0xA52A2A 3y ago

I_Am_Nous 3y ago
These things seem to go in pairs, as there is currently a new Intel CVE on the frontpage too. Someone in the Intel thread mentioned that the underlying issue may be x86 having more and more stuff piled on top of it. That's been great for compatibility, but I'm wondering if it might be worth Intel/AMD making an x86 lite that strips everything but the necessary instructions.
- tim-- 3y ago
  Isn't this partly what Intel wants to do with X86-S? https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html https://www.intel.com/content/www/us/en/developer/articles/t... Stripping away old/unused instructions from the legacy x86 arch. I would assume though that much of the new security vulnerabilities are not coming from these legacy instructions though. Surely they would be battle tested by now?
  - I_Am_Nous 3y ago
    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!
    - adrian_b 3y ago
      I have looked at the file "icebreak.asm" that is the reproducer for the Intel bug, and it contains a double REX prefix on a movsb instruction. According to all documents that have ever been published by either Intel or AMD for x86-64, it is forbidden to have more than one REX prefix in an instruction. Therefore, the instruction from "icebreak.asm" should have generated an undefined instruction exception. While in this case the behavior of the bug is extreme, by completely crashing the computer, if there are other Intel or AMD CPUs which just ignore the duplicated REX prefix, without generating the undefined instruction exception, according to their CPU architecture documentation, that is already an extremely severe bug and such lax implementations are very likely to lead to more damaging bugs, like this.
  - adrian_b 3y ago
    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.
- Mogzol 3y ago
  This exploit isn't at all related to the Intel CVE, just a coincidence they came out around the same time. And an instruction set that strips everything but the necessary instructions sounds a lot like ARM or RISC-V. No need to re-invent the wheel.
  - I_Am_Nous 3y ago
    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?
  - krasin 3y ago
    > 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/?lang=en https://developer.arm.com/documentation/ddi0602/2023-09/?lan...
- tedunangst 3y ago
  It's patch Tuesday.
  - I_Am_Nous 3y ago
    This does make sense, since they can schedule CVE announcements.
- h2odragon 3y ago
  Wild, innit? When there's a really rather nasty but Intel only bug; there's corresponding AMD bug, with name and website and all that; even if the actual vulnerability is "if you was 0wnz0red already" grade. The rest of Intel is rotten stumps but the PR department is still a sharp fang.
netcoyote 3y ago
> Specifically, a malicious hypervisor can selectively drop any writes of an AMD SEV-ES and SEV-SNP guest that occurred at an attacker-chosen point This strikes me as the thing that Raymond Chen calls "being on the other side of this airtight hatchway" [0]. That is, if you've already got control of the Hypervisor then ... you can do anything you want to the guest operating systems. Right? 0: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
- depereo 3y ago
  SEV is supposed to protect against exactly that scenario, so it's fairly serious that this protection is unwound here.
- kiririn 3y ago
  Protection against a rogue hypervisor is the main benefit of SEV. The whole point is to raise VM security to equivalent of a bare metal machine with encrypted memory and no exposed DMA channels. Protection from other guests is a nice side effect but should be a given Sadly this means AWS are still the only ones offering this kind of confidential computing without known flaws, and probably only because they don’t have researchers attempting attacks like this on their graviton CPUs
  - deleted 3y ago
    [deleted]
  - colmmacc 3y ago
    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.
crest 3y ago
Oh no the snake oil is leaking.
- deleted 3y ago
  [deleted]
binkHN 3y ago
Whenever I see something like this I'm always reminded about Theo de Raadt's, of OpenBSD fame, opinion on the topic: https://marc.info/?l=openbsd-misc&m=119318909016582 https://marc.info/?l=openbsd-misc&m=119318909016582
- cedws 3y ago
  Pretty accurate, although I do sense some irony in his comment given that OpenBSD continues to use C and their 'solution' to memory bugs is 'add a bunch of shit to the kernel for when it blows up.'
  - jpc0 3y ago
    You mean like every other OS in production?
- strstr 3y ago
  That’s a defeatist attitude. Why ever try to make progress on security if this is how you feel? It’s like saying Microsoft never should have tried to make Windows more secure than it was in the XP days.
  - lapinot 3y ago
    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.
userbinator 3y ago
In other words, this means that computations in the cloud can be performed on confidential data even if the cloud provider is untrusted or compromised. Cloud is always "someone else's computer", regardless what stupid DRM-ish crap they come up with to try to pretend that it's not. This tech only benefits the rent-seekers who try to distort the concept of ownership. In other words, this is nothing worth worrying about.
- jakobson14 3y ago
  If you can't trust the cloud host, you should be on-prem.

96 points by g0xA52A2A 3y ago

These things seem to go in pairs, as there is currently a new Intel CVE on the frontpage too. Someone in the Intel thread mentioned that the underlying issue may be x86 having more and more stuff piled on top of it. That's been great for compatibility, but I'm wondering if it might be worth Intel/AMD making an x86 lite that strips everything but the necessary instructions.

tim-- 3y ago
Isn't this partly what Intel wants to do with X86-S? https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html https://www.intel.com/content/www/us/en/developer/articles/t... Stripping away old/unused instructions from the legacy x86 arch. I would assume though that much of the new security vulnerabilities are not coming from these legacy instructions though. Surely they would be battle tested by now?
- I_Am_Nous 3y ago
  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!
  - adrian_b 3y ago
    I have looked at the file "icebreak.asm" that is the reproducer for the Intel bug, and it contains a double REX prefix on a movsb instruction. According to all documents that have ever been published by either Intel or AMD for x86-64, it is forbidden to have more than one REX prefix in an instruction. Therefore, the instruction from "icebreak.asm" should have generated an undefined instruction exception. While in this case the behavior of the bug is extreme, by completely crashing the computer, if there are other Intel or AMD CPUs which just ignore the duplicated REX prefix, without generating the undefined instruction exception, according to their CPU architecture documentation, that is already an extremely severe bug and such lax implementations are very likely to lead to more damaging bugs, like this.
- adrian_b 3y ago
  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.
Mogzol 3y ago
This exploit isn't at all related to the Intel CVE, just a coincidence they came out around the same time. And an instruction set that strips everything but the necessary instructions sounds a lot like ARM or RISC-V. No need to re-invent the wheel.
- I_Am_Nous 3y ago
  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?
- krasin 3y ago
  > 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/?lang=en https://developer.arm.com/documentation/ddi0602/2023-09/?lan...
tedunangst 3y ago
It's patch Tuesday.
- I_Am_Nous 3y ago
  This does make sense, since they can schedule CVE announcements.
h2odragon 3y ago
Wild, innit? When there's a really rather nasty but Intel only bug; there's corresponding AMD bug, with name and website and all that; even if the actual vulnerability is "if you was 0wnz0red already" grade. The rest of Intel is rotten stumps but the PR department is still a sharp fang.

netcoyote 3y ago

> Specifically, a malicious hypervisor can selectively drop any writes of an AMD SEV-ES and SEV-SNP guest that occurred at an attacker-chosen point This strikes me as the thing that Raymond Chen calls "being on the other side of this airtight hatchway" [0]. That is, if you've already got control of the Hypervisor then ... you can do anything you want to the guest operating systems. Right? 0: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

depereo 3y ago
SEV is supposed to protect against exactly that scenario, so it's fairly serious that this protection is unwound here.
kiririn 3y ago
Protection against a rogue hypervisor is the main benefit of SEV. The whole point is to raise VM security to equivalent of a bare metal machine with encrypted memory and no exposed DMA channels. Protection from other guests is a nice side effect but should be a given Sadly this means AWS are still the only ones offering this kind of confidential computing without known flaws, and probably only because they don’t have researchers attempting attacks like this on their graviton CPUs
- deleted 3y ago
  [deleted]
- colmmacc 3y ago
  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.

crest 3y ago

Oh no the snake oil is leaking.

deleted 3y ago
[deleted]

binkHN 3y ago

Whenever I see something like this I'm always reminded about Theo de Raadt's, of OpenBSD fame, opinion on the topic: https://marc.info/?l=openbsd-misc&m=119318909016582 https://marc.info/?l=openbsd-misc&m=119318909016582

cedws 3y ago
Pretty accurate, although I do sense some irony in his comment given that OpenBSD continues to use C and their 'solution' to memory bugs is 'add a bunch of shit to the kernel for when it blows up.'
- jpc0 3y ago
  You mean like every other OS in production?
strstr 3y ago
That’s a defeatist attitude. Why ever try to make progress on security if this is how you feel? It’s like saying Microsoft never should have tried to make Windows more secure than it was in the XP days.
- lapinot 3y ago
  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.

userbinator 3y ago

In other words, this means that computations in the cloud can be performed on confidential data even if the cloud provider is untrusted or compromised. Cloud is always "someone else's computer", regardless what stupid DRM-ish crap they come up with to try to pretend that it's not. This tech only benefits the rent-seekers who try to distort the concept of ownership. In other words, this is nothing worth worrying about.

jakobson14 3y ago
If you can't trust the cloud host, you should be on-prem.