4 ms·

Fabricked: Misconfiguring Infinity Fabric to Break AMD SEV-SNP

52 points by negura 5mo ago

nine_k 5mo ago
I wonder how much more expensive it is to rent the whole physical machine at all times for confidential computing purposes, compared to the losses incurred by a breach.
- UltraSane 5mo ago
  A lot more expensive and this is required for any classified data. I honestly don't think you can truly securely share a CPU with a hostile tenant because their are just too many side-channels.
  - vlovich123 5mo ago
    A hostile tenant is insufficient if you read the summary. You need a malicious hypervisor (ie your cloud provider) or a way to escape the sandbox and attack the hypervisor. Both attacks are highly unlikely in practice
- AnthonyMouse 5mo ago
  The premise of attestation is supposed to be that you can use hardware even though it's in the physical possession of someone you don't trust. It's a terrible idea, because vulnerabilities are found on a regular basis and the party you're not supposed to be trusting is then already in possession of your sensitive data when the next one is published. The premise should be abandoned and the parties attempting to get anyone to rely on it should be lampooned and run out of town. Not having a multi-tenant system is something else. There you're trying to be protected from other customers, not the provider. Excluding other tenants still wouldn't protect you against the provider, especially on systems with proprietary and potentially exploitable ring -1 hardware they could already be silently in control of even when the entire machine is allocated to you. Meanwhile for anything on the scale of an organization, having physical possession of the machine yourself isn't that expensive. People got hoodwinked when virtualization first came around because they compared the cost of having a mostly-idle physical server for each of their applications to having that many cloud VMs, and the cloud VMs were cheaper, but that isn't the right comparison. You don't compare having 100 physical machines to having 100 VMs, even if people used to use 100 physical machines for that in 2005. You compare it to having three physical machines that can each run 100 VMs, and then having physical possession of your own hardware is frequently less expensive.
- tardedmeme 5mo ago
  It's actually several times cheaper to rent a whole physical machine than to rent a single Amazon VM of equivalent compute power.
  - wmf 5mo ago
    Unless you want that whole machine to support IAM/VPC/EBS/etc and have proximity to your other VMs.
    - nullpoint420 5mo ago
      Yeah I mean sunk cost fallacy, right? If you’ve already hit critical mass in AWS of course you’re going continue investing in it. If I were to be CTO of a brand new company today, I’d probably just colocate my own servers with K8S. Much cheaper and much lower latency. 2x 1TB RAM servers with 3x 8TB high speed U.2/U.3 drives each would last years.
      - nine_k 5mo ago
        What is your plan when one of the machines needs to be taken offline for repairs? The probability is low, but the downside may be large.
        throawayonthe 5mo ago
        have three of them
        nullpoint420 5mo ago
        Haha exactly - or 4 if we’re balling
        tardedmeme 5mo ago
        How would you do that on AWS? They can shut down your VM due to hardware failures on the host. The probability is low, but the impact may be large.
- oakwhiz 5mo ago
  With sufficiently defined lease contracts it should be possible to price out the used machine risk from a new machine... Hmm
userbinator 5mo ago
More evidence that "confidential computing" is just a trick to convince people to hand over control of their computing to "someone else's machine". Never trusted the clown, and never will.
- 7e 5mo ago
  A vulnerability is a trick? All complex systems have them, but eventually they will all be formally verified and secure. Progress marches on. Unless you’d rather make your own processors along with the moonshine in your shed, of course.
  - AnthonyMouse 5mo ago
    If there is a vulnerability in a system you control, you can mitigate it until it can be patched, or if necessary disable access to it until it can be patched. If there is a vulnerability in a system controlled by an untrusted party that already has your sensitive data on it, you're pwned.
edelbitter 5mo ago
What purpose does the "news" of finding another way to break "confidential computing" serve, other than proliferate the incorrect assumption that there even was a working concept beforehand?
- stingraycharles 5mo ago
  I guess the reason you provided is the answer to the question.
eggnet 5mo ago
There are microcode updates for this already https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3034.html https://www.amd.com/en/resources/product-security/bulletin/a...
- negura 5mo ago
  but is it possible to verify that the cloud provider has applied the update?
  - nvme0n1p1 5mo ago
    /proc/cpuinfo shows the current microcode version
    - negura 5mo ago
      i don't think the information that unprivilleged VMs can obtain from that is necessarily reliable. for example with Xen as hypervisor only dom0 is privilleged (as management console for the system) and still it needs to call dedicated tooling in order to read or manage CPU features like clock speed or frequency scaling
    - edelbitter 5mo ago
      /proc/cpuinfo shows whatever the hypervisor said, often simply "microcode : 0x1000065" https://github.com/torvalds/linux/commit/518e7b94817abed94becfe6a44f1ece0d4745afe https://github.com/torvalds/linux/commit/518e7b94817abed94be... https://github.com/qemu/qemu/blob/ac6721b88df944ade0048822b2b74210f543d656/target/i386/cpu.c#L10179-L10190 https://github.com/qemu/qemu/blob/ac6721b88df944ade0048822b2...
  - eggnet 5mo ago
    Yes, it is. You do have to have some infrastructure you trust somewhere to validate an attestation report from the confidential VM.
  - wmf 5mo ago
    The SEV-SNP attestation includes the microcode version. https://www.amd.com/content/dam/amd/en/documents/developer/lss-snp-attestation.pdf https://www.amd.com/content/dam/amd/en/documents/developer/l...
procone 5mo ago
Requires an already compromised hypervisor / UEFI. Yawn.
- Borealid 5mo ago
  The only purpose of SEV is to protect a guest against the person who controls the hypervisor. So this is a threat against SEV.
- crest 5mo ago
  That's exactly what SEV is supposed to protect against. If you trust the hypervisor you don't have to encrypt your virtual machine's main memory.

52 points by negura 5mo ago

I wonder how much more expensive it is to rent the whole physical machine at all times for confidential computing purposes, compared to the losses incurred by a breach.

UltraSane 5mo ago
A lot more expensive and this is required for any classified data. I honestly don't think you can truly securely share a CPU with a hostile tenant because their are just too many side-channels.
- vlovich123 5mo ago
  A hostile tenant is insufficient if you read the summary. You need a malicious hypervisor (ie your cloud provider) or a way to escape the sandbox and attack the hypervisor. Both attacks are highly unlikely in practice
AnthonyMouse 5mo ago
The premise of attestation is supposed to be that you can use hardware even though it's in the physical possession of someone you don't trust. It's a terrible idea, because vulnerabilities are found on a regular basis and the party you're not supposed to be trusting is then already in possession of your sensitive data when the next one is published. The premise should be abandoned and the parties attempting to get anyone to rely on it should be lampooned and run out of town. Not having a multi-tenant system is something else. There you're trying to be protected from other customers, not the provider. Excluding other tenants still wouldn't protect you against the provider, especially on systems with proprietary and potentially exploitable ring -1 hardware they could already be silently in control of even when the entire machine is allocated to you. Meanwhile for anything on the scale of an organization, having physical possession of the machine yourself isn't that expensive. People got hoodwinked when virtualization first came around because they compared the cost of having a mostly-idle physical server for each of their applications to having that many cloud VMs, and the cloud VMs were cheaper, but that isn't the right comparison. You don't compare having 100 physical machines to having 100 VMs, even if people used to use 100 physical machines for that in 2005. You compare it to having three physical machines that can each run 100 VMs, and then having physical possession of your own hardware is frequently less expensive.
tardedmeme 5mo ago
It's actually several times cheaper to rent a whole physical machine than to rent a single Amazon VM of equivalent compute power.
- wmf 5mo ago
  Unless you want that whole machine to support IAM/VPC/EBS/etc and have proximity to your other VMs.
  - nullpoint420 5mo ago
    Yeah I mean sunk cost fallacy, right? If you’ve already hit critical mass in AWS of course you’re going continue investing in it. If I were to be CTO of a brand new company today, I’d probably just colocate my own servers with K8S. Much cheaper and much lower latency. 2x 1TB RAM servers with 3x 8TB high speed U.2/U.3 drives each would last years.
    - nine_k 5mo ago
      What is your plan when one of the machines needs to be taken offline for repairs? The probability is low, but the downside may be large.
      - throawayonthe 5mo ago
        have three of them
        nullpoint420 5mo ago
        Haha exactly - or 4 if we’re balling
      - tardedmeme 5mo ago
        How would you do that on AWS? They can shut down your VM due to hardware failures on the host. The probability is low, but the impact may be large.
oakwhiz 5mo ago
With sufficiently defined lease contracts it should be possible to price out the used machine risk from a new machine... Hmm

userbinator 5mo ago

More evidence that "confidential computing" is just a trick to convince people to hand over control of their computing to "someone else's machine". Never trusted the clown, and never will.

7e 5mo ago
A vulnerability is a trick? All complex systems have them, but eventually they will all be formally verified and secure. Progress marches on. Unless you’d rather make your own processors along with the moonshine in your shed, of course.
- AnthonyMouse 5mo ago
  If there is a vulnerability in a system you control, you can mitigate it until it can be patched, or if necessary disable access to it until it can be patched. If there is a vulnerability in a system controlled by an untrusted party that already has your sensitive data on it, you're pwned.

edelbitter 5mo ago

What purpose does the "news" of finding another way to break "confidential computing" serve, other than proliferate the incorrect assumption that there even was a working concept beforehand?

stingraycharles 5mo ago
I guess the reason you provided is the answer to the question.

eggnet 5mo ago

There are microcode updates for this already https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3034.html https://www.amd.com/en/resources/product-security/bulletin/a...

negura 5mo ago
but is it possible to verify that the cloud provider has applied the update?
- nvme0n1p1 5mo ago
  /proc/cpuinfo shows the current microcode version
  - negura 5mo ago
    i don't think the information that unprivilleged VMs can obtain from that is necessarily reliable. for example with Xen as hypervisor only dom0 is privilleged (as management console for the system) and still it needs to call dedicated tooling in order to read or manage CPU features like clock speed or frequency scaling
  - edelbitter 5mo ago
    /proc/cpuinfo shows whatever the hypervisor said, often simply "microcode : 0x1000065" https://github.com/torvalds/linux/commit/518e7b94817abed94becfe6a44f1ece0d4745afe https://github.com/torvalds/linux/commit/518e7b94817abed94be... https://github.com/qemu/qemu/blob/ac6721b88df944ade0048822b2b74210f543d656/target/i386/cpu.c#L10179-L10190 https://github.com/qemu/qemu/blob/ac6721b88df944ade0048822b2...
- eggnet 5mo ago
  Yes, it is. You do have to have some infrastructure you trust somewhere to validate an attestation report from the confidential VM.
- wmf 5mo ago
  The SEV-SNP attestation includes the microcode version. https://www.amd.com/content/dam/amd/en/documents/developer/lss-snp-attestation.pdf https://www.amd.com/content/dam/amd/en/documents/developer/l...

procone 5mo ago

Requires an already compromised hypervisor / UEFI. Yawn.

Borealid 5mo ago
The only purpose of SEV is to protect a guest against the person who controls the hypervisor. So this is a threat against SEV.
crest 5mo ago
That's exactly what SEV is supposed to protect against. If you trust the hypervisor you don't have to encrypt your virtual machine's main memory.