How to use SEV API 'ATTESTATION' to build trust with SEV-enabled VM?

[amazingAmy]

SEV API 'ATTESTATION' is used to generate an attestation report, i.e., SIG(pek, launch_digest||mnonce||...). 

However, this SEV API 'ATTESTATION' is called by hypervisor (qemu-kvm)  as dedicated in torvalds/linux@2c07ded06427.

It means the attestation report may be manipulated by  hypervisor. For example, VM1 and VM2 are both supposed to enable the SEV feature. However, hypervisor only enables SEV feature for VM2.

In this case, if the guest owner of VM1 requests to get attestation report, the malicious hypervisor may return the attestation report of VM2 which enables the SEV feature to cheat (if vm1's ovmf_code.fd = vm2's ovmf_code.fd ).

Thus, my question is:

1. Can the SEV API 'ATTESTATION' be directly called by guest VM without involving the interception of hypervisor? 

Meanwhile, I found that in the provisioning of the platform, the platform owner needs to send UEFI image to the guest owner, besides the cert chain, as indicated in https://github.com/AMDESE/sev-tool.

Thus, my questions are:

2. Why do the platform owner and guest owner need to negotiate UEFI image? Is the UEFI image  for platform security processor or main processor?

3. How do the guest owner verify the UEFI image? What domain knowledge should the guest owner maintain?

[lilienbm-zz]

Hi Amy, Question 1: That is a feature in SNP, where the Guest VM itself can send encrypted Guest Request commands to the PSP that only the PSP and the VM can decrypt, not the hypervisor. Please see Section 7.3 of SEV Secure Nested Paging Firmware ABI Specification <https://www.amd.com/system/files/TechDocs/56860.pdf> for more details Question 2/3: The idea is that the Guest Owner knows the hash of all the UEFI pages and any secrets being placed into the guest, because it knows the UEFI image and sends it to the hypervisor owner. The hypervisor is not necessarily trusted, so as the hypervisor passes in each UEFI/VMSA page to the PSP, the PSP will update its hash of the pages. During LaunchMeasure, the hypervisor will send that hash back to the hypervisor, who will then send that hash to the guest owner to confirm that it matches what was expected, and then the guest owner can give permission to the hypervisor owner to start the VM. For more info, please see the Proposed Provisioning Steps/Guest Owner section of the readme in https://github.com/AMDESE/sev-tool

…

On Wed, Sep 22, 2021 at 10:28 PM amy_zhang ***@***.***> wrote: SEV API 'ATTESTATION' is used to generate an attestation report, i.e., SIG(pek, launch_digest||mnonce||...). However, this SEV API 'ATTESTATION' is called by hypervisor (qemu-kvm) as dedicated in ***@***.*** <torvalds/linux@2c07ded06427>. It means the attestation report may be manipulated by hypervisor. For example, VM1 and VM2 are both supposed to enable the SEV feature. However, hypervisor only enables SEV feature for VM2. In this case, if the guest owner of VM1 requests to get attestation report, the malicious hypervisor may return the attestation report of VM2 which enables the SEV feature to cheat (if vm1's ovmf_code.fd = vm2's ovmf_code.fd ). Thus, my question is: *1. Can the SEV API 'ATTESTATION' be directly called by guest VM without involving the interception of hypervisor?* Meanwhile, I found that in the provisioning of the platform, the platform owner needs to send UEFI image to the guest owner, besides the cert chain, as indicated in https://github.com/AMDESE/sev-tool. Thus, my questions are: *2. Why do the platform owner and guest owner need to negotiate UEFI image? Is the UEFI image for platform security processor or main processor?* *3. How do the guest owner verify the UEFI image? What domain knowledge should the guest owner maintain?* — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#71>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGKHWBIYNAH7OPKISOLUWF3UDKNFHANCNFSM5ESXHVHA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[amazingAmy]

Thanks for your clarification!

May I derive the following conclusion:
In SEV/SEV-ES, the 'ATTESTATION' api cannot be used to generate valid attestation report for one specific guest, thus cannot be used to establish trust with 3rd parties.

Hi Amy, Question 1: That is a feature in SNP, where the Guest VM itself can send encrypted Guest Request commands to the PSP that only the PSP and the VM can decrypt, not the hypervisor. Please see Section 7.3 of SEV Secure Nested Paging Firmware ABI Specification https://www.amd.com/system/files/TechDocs/56860.pdf for more details Question 2/3: The idea is that the Guest Owner knows the hash of all the UEFI pages and any secrets being placed into the guest, because it knows the UEFI image and sends it to the hypervisor owner. The hypervisor is not necessarily trusted, so as the hypervisor passes in each UEFI/VMSA page to the PSP, the PSP will update its hash of the pages. During LaunchMeasure, the hypervisor will send that hash back to the hypervisor, who will then send that hash to the guest owner to confirm that it matches what was expected, and then the guest owner can give permission to the hypervisor owner to start the VM. For more info, please see the Proposed Provisioning Steps/Guest Owner section of the readme in https://github.com/AMDESE/sev-tool
…
On Wed, Sep 22, 2021 at 10:28 PM amy_zhang @.> wrote: SEV API 'ATTESTATION' is used to generate an attestation report, i.e., SIG(pek, launch_digest||mnonce||...). However, this SEV API 'ATTESTATION' is called by hypervisor (qemu-kvm) as dedicated in @. <torvalds/linux@2c07ded>. It means the attestation report may be manipulated by hypervisor. For example, VM1 and VM2 are both supposed to enable the SEV feature. However, hypervisor only enables SEV feature for VM2. In this case, if the guest owner of VM1 requests to get attestation report, the malicious hypervisor may return the attestation report of VM2 which enables the SEV feature to cheat (if vm1's ovmf_code.fd = vm2's ovmf_code.fd ). Thus, my question is: 1. Can the SEV API 'ATTESTATION' be directly called by guest VM without involving the interception of hypervisor? Meanwhile, I found that in the provisioning of the platform, the platform owner needs to send UEFI image to the guest owner, besides the cert chain, as indicated in https://github.com/AMDESE/sev-tool. Thus, my questions are: 2. Why do the platform owner and guest owner need to negotiate UEFI image? Is the UEFI image for platform security processor or main processor? 3. How do the guest owner verify the UEFI image? What domain knowledge should the guest owner maintain? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#71>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKHWBIYNAH7OPKISOLUWF3UDKNFHANCNFSM5ESXHVHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[haosanzi]

@lilienbm . Thanks for your reply.
Are there plans to support get the attestation report in SEV/SEV_ES guest?
For example, add a new hypercall type to the KVM module to support getting reports inside the guest?

[lilienbm-zz]

Question 1: No. There are no plans to enhance the SEV APIs at all. New features will be added to the SNP APIs instead.
Question 2: The UEFI image is for the x86, not the PSP. With non-secure VMs, normally the platform owner would provide the VM BIOS/UEFI image. However, since this code runs in the VM itself, it is necessarily inside the "trust boundary" of the VM. So it becomes necessary for the guest owner to KNOW what this image will be and to determine whether it is trustworthy.
Question 3: It depends on the level of trust the guest owner has in the platform owner and the BIOS/UEFI image they provide. At the extreme, a guest owner would have to read the source code for all code that is provided by anyone other than the guest owner, build it, and compare the binaries to the binaries they cannot directly control, like the BIOS/UEFI image.

As for your VM1/VM2 attack... that would be prevented by the guest owner verifying the launch digest using the LAUNCH_DIGEST capability of the SEV Firmware. This launch digest is an HMAC keyed by the PSP with the guest-owner's chosen TIK (Transport Integrity Key) that is unknown to the hypervisor.

The SEV ATTESTATION command (not the SNP ATTESTATION guest message) was added to support environments where the hypervisor is trusted by the guest owner so that the hypervisor itself can summarize a lot of very complicated transactions. If the guest owner does not trust the hypervisor, the SEV ATTESTATION command output should NOT be trusted by the guest owner.

[amazingAmy]

It's clear! Thanks a lot!

Question 1: No. There are no plans to enhance the SEV APIs at all. New features will be added to the SNP APIs instead.
Question 2: The UEFI image is for the x86, not the PSP. With non-secure VMs, normally the platform owner would provide the VM BIOS/UEFI image. However, since this code runs in the VM itself, it is necessarily inside the "trust boundary" of the VM. So it becomes necessary for the guest owner to KNOW what this image will be and to determine whether it is trustworthy.
Question 3: It depends on the level of trust the guest owner has in the platform owner and the BIOS/UEFI image they provide. At the extreme, a guest owner would have to read the source code for all code that is provided by anyone other than the guest owner, build it, and compare the binaries to the binaries they cannot directly control, like the BIOS/UEFI image.

As for your VM1/VM2 attack... that would be prevented by the guest owner verifying the launch digest using the LAUNCH_DIGEST capability of the SEV Firmware. This launch digest is an HMAC keyed by the PSP with the guest-owner's chosen TIK (Transport Integrity Key) that is unknown to the hypervisor.

The SEV ATTESTATION command (not the SNP ATTESTATION guest message) was added to support environments where the hypervisor is trusted by the guest owner so that the hypervisor itself can summarize a lot of very complicated transactions. If the guest owner does not trust the hypervisor, the SEV ATTESTATION command output should NOT be trusted by the guest owner.