aboutsummaryrefslogtreecommitdiff
path: root/target/i386/sev.c
AgeCommit message (Collapse)Author
2022-04-06qapi, target/i386/sev: Add cpu0-id to query-sev-capabilitiesDov Murik
Add a new field 'cpu0-id' to the response of query-sev-capabilities QMP command. The value of the field is the base64-encoded unique ID of CPU0 (socket 0), which can be used to retrieve the signed CEK of the CPU from AMD's Key Distribution Service (KDS). Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20220228093014.882288-1-dovmurik@linux.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-18target/i386/sev: Replace qemu_map_ram_ptr with address_space_mapDov Murik
Use address_space_map/unmap and check for errors. Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Acked-by: Brijesh Singh <brijesh.singh@amd.com> [Two lines wrapped for length - Daniel] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-18target/i386/sev: Perform padding calculations at compile-timeDov Murik
In sev_add_kernel_loader_hashes, the sizes of structs are known at compile-time, so calculate needed padding at compile-time. No functional change intended. Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-18target/i386/sev: Fail when invalid hashes table area detectedDov Murik
Commit cff03145ed3c ("sev/i386: Introduce sev_add_kernel_loader_hashes for measured linux boot", 2021-09-30) introduced measured direct boot with -kernel, using an OVMF-designated hashes table which QEMU fills. However, no checks are performed on the validity of the hashes area designated by OVMF. Specifically, if OVMF publishes the SEV_HASH_TABLE_RV_GUID entry but it is filled with zeroes, this will cause QEMU to write the hashes entries over the first page of the guest's memory (GPA 0). Add validity checks to the published area. If the hashes table area's base address is zero, or its size is too small to fit the aligned hashes table, display an error and stop the guest launch. In such case, the following error will be displayed: qemu-system-x86_64: SEV: guest firmware hashes table area is invalid (base=0x0 size=0x0) Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reported-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-18target/i386/sev: Rephrase error message when no hashes table in guest firmwareDov Murik
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Acked-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-18target/i386/sev: Add kernel hashes only if sev-guest.kernel-hashes=onDov Murik
Commit cff03145ed3c ("sev/i386: Introduce sev_add_kernel_loader_hashes for measured linux boot", 2021-09-30) introduced measured direct boot with -kernel, using an OVMF-designated hashes table which QEMU fills. However, if OVMF doesn't designate such an area, QEMU would completely abort the VM launch. This breaks launching with -kernel using older OVMF images which don't publish the SEV_HASH_TABLE_RV_GUID. Fix that so QEMU will only look for the hashes table if the sev-guest kernel-hashes option is set to on. Otherwise, QEMU won't look for the designated area in OVMF and won't fill that area. To enable addition of kernel hashes, launch the guest with: -object sev-guest,...,kernel-hashes=on Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reported-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-18qapi/qom,target/i386: sev-guest: Introduce kernel-hashes=on|off optionDov Murik
Introduce new boolean 'kernel-hashes' option on the sev-guest object. It will be used to to decide whether to add the hashes of kernel/initrd/cmdline to SEV guest memory when booting with -kernel. The default value is 'off'. Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Acked-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-10-13target/i386/sev: Use local variable for kvm_sev_launch_measureDov Murik
The struct kvm_sev_launch_measure has a constant and small size, and therefore we can use a regular local variable for it instead of allocating and freeing heap memory for it. Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20211011173026.2454294-3-dovmurik@linux.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: Use local variable for kvm_sev_launch_startDov Murik
The struct kvm_sev_launch_start has a constant and small size, and therefore we can use a regular local variable for it instead of allocating and freeing heap memory for it. Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20211011173026.2454294-2-dovmurik@linux.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13monitor: Reduce hmp_info_sev() declarationPhilippe Mathieu-Daudé
While being conditionally used for TARGET_I386 in hmp-commands-info.hx, hmp_info_sev() is declared for all targets. Reduce its declaration to target including "monitor/hmp-target.h". This is a minor cleanup. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211007161716.453984-23-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: Move qmp_query_sev() & hmp_info_sev() to sev.cPhilippe Mathieu-Daudé
Move qmp_query_sev() & hmp_info_sev()() from monitor.c to sev.c and make sev_get_info() static. We don't need the stub anymore, remove it. Add a stub for hmp_info_sev(). Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211007161716.453984-22-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: Move qmp_query_sev_launch_measure() to sev.cPhilippe Mathieu-Daudé
Move qmp_query_sev_launch_measure() from monitor.c to sev.c and make sev_get_launch_measurement() static. We don't need the stub anymore, remove it. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211007161716.453984-21-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: Move qmp_query_sev_capabilities() to sev.cPhilippe Mathieu-Daudé
Move qmp_query_sev_capabilities() from monitor.c to sev.c and make sev_get_capabilities() static. We don't need the stub anymore, remove it. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211007161716.453984-20-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: Move qmp_sev_inject_launch_secret() to sev.cPhilippe Mathieu-Daudé
Move qmp_sev_inject_launch_secret() from monitor.c to sev.c and make sev_inject_launch_secret() static. We don't need the stub anymore, remove it. Previously with binaries built without SEV, management layer was getting an empty response: { "execute": "sev-inject-launch-secret", "arguments": { "packet-header": "mypkt", "secret": "mypass", "gpa": 4294959104 } } { "return": { } } Now the response is explicit, mentioning the feature is disabled: { "execute": "sev-inject-launch-secret", "arguments": { "packet-header": "mypkt", "secret": "mypass", "gpa": 4294959104 } } { "error": { "class": "GenericError", "desc": "this feature or command is not currently supported" } } Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211007161716.453984-19-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: Move qmp_query_sev_attestation_report() to sev.cPhilippe Mathieu-Daudé
Move qmp_query_sev_attestation_report() from monitor.c to sev.c and make sev_get_attestation_report() static. We don't need the stub anymore, remove it. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211007161716.453984-18-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: Rename sev_i386.h -> sev.hPhilippe Mathieu-Daudé
SEV is a x86 specific feature, and the "sev_i386.h" header is already in target/i386/. Rename it as "sev.h" to simplify. Patch created mechanically using: $ git mv target/i386/sev_i386.h target/i386/sev.h $ sed -i s/sev_i386.h/sev.h/ $(git grep -l sev_i386.h) Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20211007161716.453984-15-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: Use g_autofree in sev_launch_get_measure()Philippe Mathieu-Daudé
Use g_autofree to remove a pair of g_free/goto. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211007161716.453984-13-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: sev_get_attestation_report use g_autofreeDr. David Alan Gilbert
Removes a whole bunch of g_free's and a goto. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Connor Kuehl <ckuehl@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Message-Id: <20210603113017.34922-1-dgilbert@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211007161716.453984-12-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: Remove sev_get_me_mask()Philippe Mathieu-Daudé
Unused dead code makes review harder, so remove it. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Connor Kuehl <ckuehl@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211007161716.453984-10-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-13target/i386/sev: Prefix QMP errors with 'SEV'Philippe Mathieu-Daudé
Multiple errors might be reported to the monitor, better to prefix the SEV ones so we can distinct them. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20211007161716.453984-6-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-05sev/i386: Introduce sev_add_kernel_loader_hashes for measured linux bootDov Murik
Add the sev_add_kernel_loader_hashes function to calculate the hashes of the kernel/initrd/cmdline and fill a designated OVMF encrypted hash table area. For this to work, OVMF must support an encrypted area to place the data which is advertised via a special GUID in the OVMF reset table. The hashes of each of the files is calculated (or the string in the case of the cmdline with trailing '\0' included). Each entry in the hashes table is GUID identified and since they're passed through the sev_encrypt_flash interface, the hashes will be accumulated by the AMD PSP measurement (SEV_LAUNCH_MEASURE). Co-developed-by: James Bottomley <jejb@linux.ibm.com> Signed-off-by: James Bottomley <jejb@linux.ibm.com> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210930054915.13252-2-dovmurik@linux.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30target/i386: Fix memory leak in sev_read_file_base64()Peter Maydell
In sev_read_file_base64() we call g_file_get_contents(), which allocates memory for the file contents. We then base64-decode the contents (which allocates another buffer for the decoded data), but forgot to free the memory for the original file data. Use g_autofree to ensure that the file data is freed. Fixes: Coverity CID 1459997 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210820165650.2839-1-peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-08-26error: Use error_fatal to simplify obvious fatal errors (again)Markus Armbruster
We did this with scripts/coccinelle/use-error_fatal.cocci before, in commit 50beeb68094 and 007b06578ab. This commit cleans up rarer variations that don't seem worth matching with Coccinelle. Cc: Thomas Huth <thuth@redhat.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Peter Xu <peterx@redhat.com> Cc: Juan Quintela <quintela@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210720125408.387910-2-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-06-01sev: add missing firmware error conditionsConnor Kuehl
The SEV userspace header[1] exports a couple of other error conditions that aren't listed in QEMU's SEV implementation, so let's just round out the list. [1] linux-headers/linux/psp-sev.h Signed-off-by: Connor Kuehl <ckuehl@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210430134830.254741-3-ckuehl@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-06-01sev: use explicit indices for mapping firmware error codes to stringsConnor Kuehl
This can help lower any margin for error when making future additions to the list, especially if they're made out of order. While doing so, make capitalization of ASID consistent with its usage in the SEV firmware spec (Asid -> ASID). Signed-off-by: Connor Kuehl <ckuehl@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210430134830.254741-2-ckuehl@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-06-01target/i386/sev: add support to query the attestation reportBrijesh Singh
The SEV FW >= 0.23 added a new command that can be used to query the attestation report containing the SHA-256 digest of the guest memory and VMSA encrypted with the LAUNCH_UPDATE and sign it with the PEK. Note, we already have a command (LAUNCH_MEASURE) that can be used to query the SHA-256 digest of the guest memory encrypted through the LAUNCH_UPDATE. The main difference between previous and this command is that the report is signed with the PEK and unlike the LAUNCH_MEASURE command the ATTESATION_REPORT command can be called while the guest is running. Add a QMP interface "query-sev-attestation-report" that can be used to get the report encoded in base64. Cc: James Bottomley <jejb@linux.ibm.com> Cc: Tom Lendacky <Thomas.Lendacky@amd.com> Cc: Eric Blake <eblake@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org Reviewed-by: James Bottomley <jejb@linux.ibm.com> Tested-by: James Bottomley <jejb@linux.ibm.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Connor Kuehl <ckuehl@redhat.com> Message-Id: <20210429170728.24322-1-brijesh.singh@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-13numa: Teach ram block notifiers about resizeable ram blocksDavid Hildenbrand
Ram block notifiers are currently not aware of resizes. To properly handle resizes during migration, we want to teach ram block notifiers about resizeable ram. Introduce the basic infrastructure but keep using max_size in the existing notifiers. Supply the max_size when adding and removing ram blocks. Also, notify on resizes. Acked-by: Paul Durrant <paul@xen.org> Reviewed-by: Peter Xu <peterx@redhat.com> Cc: xen-devel@lists.xenproject.org Cc: haxm-team@intel.com Cc: Paul Durrant <paul@xen.org> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Wenchao Wang <wenchao.wang@intel.com> Cc: Colin Xu <colin.xu@intel.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210429112708.12291-3-david@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2021-05-02Do not include exec/address-spaces.h if it's not really necessaryThomas Huth
Stop including exec/address-spaces.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-5-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-03-09sysemu: Let VMChangeStateHandler take boolean 'running' argumentPhilippe Mathieu-Daudé
The 'running' argument from VMChangeStateHandler does not require other value than 0 / 1. Make it a plain boolean. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210111152020.1422021-3-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-02-16sev/i386: Enable an SEV-ES guest based on SEV policyTom Lendacky
Update the sev_es_enabled() function return value to be based on the SEV policy that has been specified. SEV-ES is enabled if SEV is enabled and the SEV-ES policy bit is set in the policy object. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Venu Busireddy <venu.busireddy@oracle.com> Message-Id: <c69f81c6029f31fc4c52a9f35f1bd704362476a5.1611682609.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-16sev/i386: Allow AP booting under SEV-ESPaolo Bonzini
When SEV-ES is enabled, it is not possible modify the guests register state after it has been initially created, encrypted and measured. Normally, an INIT-SIPI-SIPI request is used to boot the AP. However, the hypervisor cannot emulate this because it cannot update the AP register state. For the very first boot by an AP, the reset vector CS segment value and the EIP value must be programmed before the register has been encrypted and measured. Search the guest firmware for the guest for a specific GUID that tells Qemu the value of the reset vector to use. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <22db2bfb4d6551aed661a9ae95b4fdbef613ca21.1611682609.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-16sev/i386: Require in-kernel irqchip support for SEV-ES guestsTom Lendacky
In prep for AP booting, require the use of in-kernel irqchip support. This lessens the Qemu support burden required to boot APs. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Venu Busireddy <venu.busireddy@oracle.com> Message-Id: <e9aec5941e613456f0757f5a73869cdc5deea105.1611682609.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-16sev/i386: Add initial support for SEV-ESTom Lendacky
Provide initial support for SEV-ES. This includes creating a function to indicate the guest is an SEV-ES guest (which will return false until all support is in place), performing the proper SEV initialization and ensuring that the guest CPU state is measured as part of the launch. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Co-developed-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Venu Busireddy <venu.busireddy@oracle.com> Message-Id: <2e6386cbc1ddeaf701547dd5677adf5ddab2b6bd.1611682609.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-08confidential guest support: Move SEV initialization into arch specific codeDavid Gibson
While we've abstracted some (potential) differences between mechanisms for securing guest memory, the initialization is still specific to SEV. Given that, move it into x86's kvm_arch_init() code, rather than the generic kvm_init() code. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
2021-02-08confidential guest support: Introduce cgs "ready" flagDavid Gibson
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>
2021-02-08sev: Add Error ** to sev_kvm_init()David Gibson
This allows failures to be reported richly and idiomatically. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2021-02-08confidential guest support: Rework the "memory-encryption" propertyDavid Gibson
Currently the "memory-encryption" property is only looked at once we get to kvm_init(). Although protection of guest memory from the hypervisor isn't something that could really ever work with TCG, it's not conceptually tied to the KVM accelerator. In addition, the way the string property is resolved to an object is almost identical to how a QOM link property is handled. So, create a new "confidential-guest-support" link property which sets this QOM interface link directly in the machine. For compatibility we keep the "memory-encryption" property, but now implemented in terms of the new property. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2021-02-08sev: Remove false abstraction of flash encryptionDavid Gibson
When AMD's SEV memory encryption is in use, flash memory banks (which are initialed by pc_system_flash_map()) need to be encrypted with the guest's key, so that the guest can read them. That's abstracted via the kvm_memcrypt_encrypt_data() callback in the KVM state.. except, that it doesn't really abstract much at all. For starters, the only call site is in code specific to the 'pc' family of machine types, so it's obviously specific to those and to x86 to begin with. But it makes a bunch of further assumptions that need not be true about an arbitrary confidential guest system based on memory encryption, let alone one based on other mechanisms: * it assumes that the flash memory is defined to be encrypted with the guest key, rather than being shared with hypervisor * it assumes that that hypervisor has some mechanism to encrypt data into the guest, even though it can't decrypt it out, since that's the whole point * the interface assumes that this encrypt can be done in place, which implies that the hypervisor can write into a confidential guests's memory, even if what it writes isn't meaningful So really, this "abstraction" is actually pretty specific to the way SEV works. So, this patch removes it and instead has the PC flash initialization code call into a SEV specific callback. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2021-02-08confidential guest support: Introduce new confidential guest support classDavid Gibson
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>
2020-12-10sev: add sev-inject-launch-secretTobin Feldman-Fitzthum
AMD SEV allows a guest owner to inject a secret blob into the memory of a virtual machine. The secret is encrypted with the SEV Transport Encryption Key and integrity is guaranteed with the Transport Integrity Key. Although QEMU facilitates the injection of the launch secret, it cannot access the secret. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Message-Id: <20201027170303.47550-1-tobin@linux.ibm.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-18Use OBJECT_DECLARE_SIMPLE_TYPE when possibleEduardo Habkost
This converts existing DECLARE_INSTANCE_CHECKER usage to OBJECT_DECLARE_SIMPLE_TYPE when possible. $ ./scripts/codeconverter/converter.py -i \ --pattern=AddObjectDeclareSimpleType $(git grep -l '' -- '*.[ch]') Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Paul Durrant <paul@xen.org> Message-Id: <20200916182519.415636-6-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-09Use DECLARE_*CHECKER* macrosEduardo Habkost
Generated using: $ ./scripts/codeconverter/converter.py -i \ --pattern=TypeCheckMacro $(git grep -l '' -- '*.[ch]') Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-12-ehabkost@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-13-ehabkost@redhat.com> Message-Id: <20200831210740.126168-14-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-09Move QOM typedefs and add missing includesEduardo Habkost
Some typedefs and macros are defined after the type check macros. This makes it difficult to automatically replace their definitions with OBJECT_DECLARE_TYPE. Patch generated using: $ ./scripts/codeconverter/converter.py -i \ --pattern=QOMStructTypedefSplit $(git grep -l '' -- '*.[ch]') which will split "typdef struct { ... } TypedefName" declarations. Followed by: $ ./scripts/codeconverter/converter.py -i --pattern=MoveSymbols \ $(git grep -l '' -- '*.[ch]') which will: - move the typedefs and #defines above the type check macros - add missing #include "qom/object.h" lines if necessary Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-9-ehabkost@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-10-ehabkost@redhat.com> Message-Id: <20200831210740.126168-11-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-02target/i386/sev: Plug memleak in sev_read_file_base64Pan Nengyuan
Missing g_error_free() in sev_read_file_base64() error path. Fix that. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Message-Id: <20200831134315.1221-5-pannengyuan@huawei.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-07-10target/i386: sev: fail query-sev-capabilities if QEMU cannot use SEVPaolo Bonzini
In some cases, such as if the kvm-amd "sev" module parameter is set to 0, SEV will be unavailable but query-sev-capabilities will still return all the information. This tricks libvirt into erroneously reporting that SEV is available. Check the actual usability of the feature and return the appropriate error if QEMU cannot use KVM or KVM cannot use SEV. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-07-10target/i386: sev: provide proper error reporting for query-sev-capabilitiesPaolo Bonzini
The query-sev-capabilities was reporting errors through error_report; change it to use Error** so that the cause of the failure is clearer. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-07-02target/i386: sev: Use ram_block_discard_disable()David Hildenbrand
AMD SEV will pin all guest memory, mark discarding of RAM broken. At the time this is called, we cannot have anyone active that relies on discards to work properly - let's still implement error handling. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-8-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-12target/i386: sev: Unify SEVState and SevGuestStateDavid Gibson
SEVState is contained with SevGuestState. We've now fixed redundancies and name conflicts, so there's no real point to the nested structure. Just move all the fields of SEVState into SevGuestState. This eliminates the SEVState structure, which as a bonus removes the confusion with the SevState enum. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200604064219.436242-10-david@gibson.dropbear.id.au> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-12target/i386: sev: Remove redundant handle fieldDavid Gibson
The user can explicitly specify a handle via the "handle" property wired to SevGuestState::handle. That gets passed to the KVM_SEV_LAUNCH_START ioctl() which may update it, the final value being copied back to both SevGuestState::handle and SEVState::handle. AFAICT, nothing will be looking SEVState::handle before it and SevGuestState::handle have been updated from the ioctl(). So, remove the field and just use SevGuestState::handle directly. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200604064219.436242-9-david@gibson.dropbear.id.au> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-12target/i386: sev: Remove redundant policy fieldDavid Gibson
SEVState::policy is set from the final value of the policy field in the parameter structure for the KVM_SEV_LAUNCH_START ioctl(). But, AFAICT that ioctl() won't ever change it from the original supplied value which comes from SevGuestState::policy. So, remove this field and just use SevGuestState::policy directly. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200604064219.436242-8-david@gibson.dropbear.id.au> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>