Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 1 Feb 2023 09:00:30 +1100 | Subject | Re: [PATCH RFC v7 52/64] KVM: SVM: Provide support for SNP_GUEST_REQUEST NAE event | From | Alexey Kardashevskiy <> |
| |
On 01/02/2023 08:21, Tom Lendacky wrote: > On 1/31/23 14:21, Alexey Kardashevskiy wrote: >> On 01/02/2023 03:23, Tom Lendacky wrote: >>> On 1/30/23 19:54, Alexey Kardashevskiy wrote: >>>> On 11/1/23 13:01, Kalra, Ashish wrote: >>>>> On 1/10/2023 6:48 PM, Alexey Kardashevskiy wrote: >>>>>> On 10/1/23 19:33, Kalra, Ashish wrote: >>>>>>> On 1/9/2023 8:28 PM, Alexey Kardashevskiy wrote: >>>>>>>> On 10/1/23 10:41, Kalra, Ashish wrote: >>>>>>>>> On 1/8/2023 9:33 PM, Alexey Kardashevskiy wrote: >>>>>>>>>> On 15/12/22 06:40, Michael Roth wrote: >>>>>>>>>>> From: Brijesh Singh <brijesh.singh@amd.com> >>>>>>>>>>> >>>>>>>>>>> Version 2 of GHCB specification added the support for two SNP >>>>>>>>>>> Guest >>>>>>>>>>> Request Message NAE events. The events allows for an SEV-SNP >>>>>>>>>>> guest to >>>>>>>>>>> make request to the SEV-SNP firmware through hypervisor using >>>>>>>>>>> the >>>>>>>>>>> SNP_GUEST_REQUEST API define in the SEV-SNP firmware >>>>>>>>>>> specification. >>>>>>>>>>> >>>>>>>>>>> The SNP_EXT_GUEST_REQUEST is similar to SNP_GUEST_REQUEST >>>>>>>>>>> with the >>>>>>>>>>> difference of an additional certificate blob that can be >>>>>>>>>>> passed through >>>>>>>>>>> the SNP_SET_CONFIG ioctl defined in the CCP driver. The CCP >>>>>>>>>>> driver >>>>>>>>>>> provides snp_guest_ext_guest_request() that is used by the >>>>>>>>>>> KVM to get >>>>>>>>>>> both the report and certificate data at once. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> >>>>>>>>>>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> >>>>>>>>>>> Signed-off-by: Michael Roth <michael.roth@amd.com> >>>>>>>>>>> --- > >>>> >>>> And GET ioctls() return what SET passed on (not something the >>>> firware returned, for example), what is ever going to call SET? The >>>> userspace can >>> >>> As stated above, the firmware already has the information needed to >>> sign the attestation report. The SET IOCTL is used to supply the >>> certficates to the guest for validation of the attestation report. >> >> >> Does the firmware have to have all certificates beforehand? How does >> the firmware choose which certificate to use for a specific VM, or >> just signs all reports with all certificates it knows? > > From the SNP API spec, the firmware uses the VCEK, which is derived > from chip-unique secrets, to sign the attestation report.
Does the firmware derive it? How does the guest gets to know it? (forgive me my ignorance)
> The guest can then use the returned VCEK certificate, the ASK > certificate and ARK certificate from the extended guest request to > validate the attestation report.
>> >> >>> This reduces the traffic and complexity of the guest requesting the >>> certficates from the KDS. >> >> Guest <-> HV interaction is clear, I am only wondering about HV <-> FW. > > I'm not sure what you mean here. The HV doesn't put the signing key in > the firmware, it is derived.
Those ioctls() are in the HV and they take certificates which then get sent to the guest but not to the firmware. The firmware signs a report with a key and the guest needs another half of it to verify the report. Sadly I do not know cryptography enough.
-- Alexey
| ![\](/images/icornerr.gif) |