AMD Secure Nested Paging IOMMU For SEV-SNP Lands In Linux 5.10

[phoronix]

Phoronix: AMD Secure Nested Paging For SEV-SNP Lands In Linux 5.10

In addition to Linux 5.10 supporting SEV-ES as the "encrypted state" for AMD EPYC's Secure Encrypted Virtualization, this kernel is also adding Secure Nested Paging (SNP) support to the AMD IOMMU driver as part of their next-generation SEV-SNP security...

http://www.phoronix.com/scan.php?page=news_item&px=AMD-SEV-SNP-IOMMU-Linux-5.10

[zcansi]

You really have to admire AMD for taking a slow, iterative approach to trusted computing for the cloud.

Sure, they are only now starting to target levels of security targeted from the start by Intel's SGX, but SGX was very limited and was still broken many times by security researchers, meaning its utility has been arguably less than AMD's work so far (it fails to uphold the most ambitious security goals, and is too limited to scale down to other purposes).

That said, I'm very curious if we will ever see a truly watertight (at least, by design) implementation of trusted computing for the cloud. For example, Google's current effort (which is the most ambitious so far, I think) uses the previous version of SEV (obviously, as processors for this new version are not out yet) which has some gaps. But even if they upgrade it to the new version of SEV, if you look at what kind of attestation you can actually get, you get an attestation that involves trusted components built and certified by Google that are not open to inspection. The attestation value also contains a boolean indicating whether "validation passed" and the docs do not appear to mention how anyone could actually meaningfully verify the attestation themselves....

I don't see how anybody can actually trust this more than any other cloud VM unless the entire trusted computing base is open to testing and inspection. Until then this is a great extra layer of security for things you wouldn't mind putting in the cloud anyway, but doesn't really meaningfully provide assurances against a cloud provider's own management and debug tools.

That said, maybe with this new version protecting against DMA, perhaps that's all they needed to move the last Google-owned parts out of the TCB, and we will only need to trust in the security of AMD's signing keys and their platform security processor (which is at least accessible to security researchers).

[deusexmachina]

Except zero public cloud providers except Google have AMD security features enabled... Not totally AMD's fault, but I don't think they should sell to public cloud providers without some agreement to use their hardware correctly.

[Jabberwocky]

You really have to admire AMD for taking a slow, iterative approach to trusted computing for the cloud.

Sure, they are only now starting to target levels of security targeted from the start by Intel's SGX, but SGX was very limited and was still broken many times by security researchers, meaning its utility has been arguably less than AMD's work so far (it fails to uphold the most ambitious security goals, and is too limited to scale down to other purposes).

That said, I'm very curious if we will ever see a truly watertight (at least, by design) implementation of trusted computing for the cloud. For example, Google's current effort (which is the most ambitious so far, I think) uses the previous version of SEV (obviously, as processors for this new version are not out yet) which has some gaps. But even if they upgrade it to the new version of SEV, if you look at what kind of attestation you can actually get, you get an attestation that involves trusted components built and certified by Google that are not open to inspection. The attestation value also contains a boolean indicating whether "validation passed" and the docs do not appear to mention how anyone could actually meaningfully verify the attestation themselves....

I don't see how anybody can actually trust this more than any other cloud VM unless the entire trusted computing base is open to testing and inspection. Until then this is a great extra layer of security for things you wouldn't mind putting in the cloud anyway, but doesn't really meaningfully provide assurances against a cloud provider's own management and debug tools.

That said, maybe with this new version protecting against DMA, perhaps that's all they needed to move the last Google-owned parts out of the TCB, and we will only need to trust in the security of AMD's signing keys and their platform security processor (which is at least accessible to security researchers).

+1 It should be policy to broadcast security extentions to guest VM. Regulation is still playing catch up in this industry which is both good and bad. In this case it's not difficult to implement and does not hinder growth. I think it would be good thing to make cloud computing more competitive. The point is just that users/clients should know which levels are enforced.