Michael Roth <[email protected]> writes: > The GHCB specification[1] defines a VMGEXIT-based Guest Request > hypercall to allow an SNP guest to issue encrypted requests directly to > SNP firmware to do things like query the attestation report for the > guest. These are generally handled purely in the kernel. > > In some cases, it's useful for the host to be able to additionally > supply the certificate chain for the signing key that SNP firmware uses > to sign these attestation reports. To allow for this, the GHCB > specification defines an Extended Guest Request where this certificate > data (along with other accompanying data) can be provided in a special > format described in the GHCB spec. This certificate data may be global > or guest-specific depending on how the guest was configured. Rather than > providing interfaces to manage these within the kernel, KVM provides a > new KVM_EXIT_SNP_REQ_CERTS exit to request the certificate contents from > userspace. Implement support for that in QEMU. > > To synchronize delivery of the certificates to the guest in a way where > they will not be rendered invalid by updates to SNP firmware or > attestation signing/endorsement keys by management tools outside the > purview of QEMU, it is expected by users of KVM_EXIT_SNP_REQ_CERTS to > obtain a shared/read lock on the certificate file prior to delivering > them back to KVM. Only after this will the attestation report be > retrieved from firmware and bundled with the certificate data, so QEMU > must continue to hold the file lock until KVM confirms that the > attestation report has been retrieved/bundled. > > This confirmation is done by way of the kvm_immediate_exit callback > infrastructure that was introduced in a prior commit. Once the callback > is issued (after the next KVM_RUN), the attestation report will have > been fetched, so the report and certificate data fetched by QEMU should > be consistent with one another, and the certificate lock can then be > released. The included documentation updates have more details on how > this is handled. > > [1] "Guest Hypervisor Communication Block (GHCB) Standardization", > https://www.amd.com/en/developer/sev.html > > Co-developed-by: Melody Wang <[email protected]> > Signed-off-by: Melody Wang <[email protected]> > Signed-off-by: Michael Roth <[email protected]>
QAPI schema Acked-by: Markus Armbruster <[email protected]>
