lkml.org 
[lkml]   [2023]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH RFC v7 52/64] KVM: SVM: Provide support for SNP_GUEST_REQUEST NAE event
From


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

\
 
 \ /
  Last update: 2023-03-27 00:04    [W:0.093 / U:6.892 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site