lkml.org 
[lkml]   [2022]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH Part2 v6 17/49] crypto: ccp: Add the SNP_{SET,GET}_EXT_CONFIG command
    From
    On 8/8/22 14:27, Dionna Amalie Glaze wrote:
    > To preface, I don't want to delay this patch set, only have the
    > conversation at the most appropriate place.
    >
    >>
    >>> The SEV-SNP firmware provides the SNP_CONFIG command used to set the
    >>> system-wide configuration value for SNP guests. The information includes
    >>> the TCB version string to be reported in guest attestation reports.
    >>
    >
    > The system-wide aspect of this makes me wonder if we can also have a
    > VM instance-specific extension. This is important for the use case
    > that we may see secure boot variables included in the launch
    > measurement, making offline signing of the UEFI image impossible. We
    > can't sign the cross-product of all UEFI builds and every user's EFI
    > variables. We'd like to include an instance-specific certificate that
    > specifies the platform-endorsed golden measurement of the UEFI.
    >
    > An alternative that doesn't require a change to the kernel is to just
    > make this certificate fetchable from a FAMILY_ID-keyed, predetermined
    > URL prefix + IMAGE_ID + '.crt', but this requires a download (and
    > continuous hosting) to do something as routine as collecting an
    > attestation report. It's up to the upstream community to determine if
    > that is an acceptable cost to keep the complexity of a certificate
    > table merge operation out of the kernel.
    >
    > The SNP API specification gives an interpretation to the data blob

    That's the GHCB specification, not the SNP API.

    > here as a table of GUID/offset pairs followed by data blobs that
    > presumably are at the appropriate offsets into the data pages. The
    > spec allows for the host to add any number of GUID/offset pairs it
    > wants, with 3 specific GUIDs recommended for the AMD PSP certificate
    > chain.
    >
    > The snp_guest_ext_guest_request function in ccp is what passes back
    > the certificate data that was previously stored, so I'm wondering if
    > it can take an extra (pointer,len) pair of VM instance certificate
    > data to merge with the host certificate data before returning to the
    > guest. The new required length is the sum total of both the header
    > certs and instance certs. The operation to copy the data is no longer
    > a memcpy but a header merge that tracks the offset shifts caused by a
    > larger header and other certificates in the remaining data pages.
    >
    > I can propose my own patch on top of this v6 patch set that adds a KVM
    > ioctl like KVM_{GET,SET}_INSTANCE_SNP_EXT_CONFIG and then pass along

    Would it be burden to supply all the certificates, both system and per-VM,
    in this KVM call? On the SNP Extended Guest Request, the hypervisor could
    just check if there is a per-VM blob and return that or else return the
    system-wide blob (if present).

    Thanks,
    Tom


    > the stored certificate blob in the request call. I'd prefer to have
    > the design agreed upon upfront though.
    >

    \
     
     \ /
      Last update: 2022-08-08 23:34    [W:6.449 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site