lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 13 Oct 2022 07:58:07 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Dionna Amalie Glaze <dionnaglaze@...gle.com>,
        "Kalra, Ashish" <ashish.kalra@....com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH 1/2] x86/sev: Add KVM commands for instance certs

On 10/12/22 20:02, Dionna Amalie Glaze wrote:
>>>> +    /* Page-align the length */
>>>> +    length = (params.certs_len + PAGE_SIZE - 1) & PAGE_MASK;
>>>
>>> Probably can use PAGE_ALIGN() here.
>>>
> 
> Ah, thanks. Will add in v2.
> 
>>
>> Though, one thing i don't understand is that why do we need to issue
>> the SNP_GUEST_REQUEST to FW if we are going to return the VMM
>> overriden certs back to the guest ?
>>
>> Thanks,
>> Ashish
> 
> If I'm reading the spec right, certs are supposed to come along with
> the guest request when the user issues an extended guest request. If
> the length is correct, we issue the command to get the report and we
> simply override what the psp returns for the certs.

The SNP Extended Guest Request doesn't override anything from the PSP, it 
just supplies additional data associated with the MSG_REPORT_REQ so that 
an additional call does not have to be made to obtain the certificate 
chain needed validate the report.

The idea is to not have to make two calls, since, theoretically, it is 
possible for the guest to be migrated in between a MSG_REPORT_REQ call and 
the call to obtain the certificates, at which point the VCEK would not match.

Thanks,
Tom

> 
> Is that your understanding too? If so, are you saying there's a bug in
> this implementation?
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ