[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4c642bd1-5f1c-292e-398f-eed699db590d@amd.com>
Date: Wed, 1 Feb 2023 09:00:30 +1100
From: Alexey Kardashevskiy <aik@....com>
To: Tom Lendacky <thomas.lendacky@....com>,
"Kalra, Ashish" <ashish.kalra@....com>,
Michael Roth <michael.roth@....com>, kvm@...r.kernel.org
Cc: linux-coco@...ts.linux.dev, linux-mm@...ck.org,
linux-crypto@...r.kernel.org, x86@...nel.org,
linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
jroedel@...e.de, hpa@...or.com, ardb@...nel.org,
pbonzini@...hat.com, seanjc@...gle.com, vkuznets@...hat.com,
wanpengli@...cent.com, jmattson@...gle.com, luto@...nel.org,
dave.hansen@...ux.intel.com, slp@...hat.com, pgonda@...gle.com,
peterz@...radead.org, srinivas.pandruvada@...ux.intel.com,
rientjes@...gle.com, dovmurik@...ux.ibm.com, tobin@....com,
bp@...en8.de, vbabka@...e.cz, kirill@...temov.name,
ak@...ux.intel.com, tony.luck@...el.com, marcorr@...gle.com,
sathyanarayanan.kuppuswamy@...ux.intel.com, alpergun@...gle.com,
dgilbert@...hat.com, jarkko@...nel.org, harald@...fian.com,
Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH RFC v7 52/64] KVM: SVM: Provide support for
SNP_GUEST_REQUEST NAE event
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@....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@....com>
>>>>>>>>>>> Signed-off-by: Ashish Kalra <ashish.kalra@....com>
>>>>>>>>>>> Signed-off-by: Michael Roth <michael.roth@....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
Powered by blists - more mailing lists