summaryrefslogtreecommitdiffstats
path: root/include/exec/confidential-guest-support.h
Commit message (Collapse)AuthorAgeFilesLines
* confidential guest support: Introduce cgs "ready" flagDavid Gibson2021-02-081-0/+24
| | | | | | | | | | | | | | | | | | | | | The platform specific details of mechanisms for implementing confidential guest support may require setup at various points during initialization. Thus, it's not really feasible to have a single cgs initialization hook, but instead each mechanism needs its own initialization calls in arch or machine specific code. However, to make it harder to have a bug where a mechanism isn't properly initialized under some circumstances, we want to have a common place, late in boot, where we verify that cgs has been initialized if it was requested. This patch introduces a ready flag to the ConfidentialGuestSupport base type to accomplish this, which we verify in qemu_machine_creation_done(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
* confidential guest support: Introduce new confidential guest support classDavid Gibson2021-02-081-0/+38
Several architectures have mechanisms which are designed to protect guest memory from interference or eavesdropping by a compromised hypervisor. AMD SEV does this with in-chip memory encryption and Intel's TDX can do similar things. POWER's Protected Execution Framework (PEF) accomplishes a similar goal using an ultravisor and new memory protection features, instead of encryption. To (partially) unify handling for these, this introduces a new ConfidentialGuestSupport QOM base class. "Confidential" is kind of vague, but "confidential computing" seems to be the buzzword about these schemes, and "secure" or "protected" are often used in connection to unrelated things (such as hypervisor-from-guest or guest-from-guest security). The "support" in the name is significant because in at least some of the cases it requires the guest to take specific actions in order to protect itself from hypervisor eavesdropping. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>