aboutsummaryrefslogtreecommitdiff
path: root/target/i386/sev.c
AgeCommit message (Collapse)AuthorFilesLines
2020-07-10target/i386: sev: fail query-sev-capabilities if QEMU cannot use SEVPaolo Bonzini1-0/+9
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 Bonzini1-9/+9
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 Hildenbrand1-0/+7
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 Gibson1-45/+34
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 Gibson1-8/+4
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 Gibson1-5/+2
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>
2020-06-12target/i386: sev: Remove redundant cbitpos and reduced_phys_bits fieldsDavid Gibson1-12/+7
The SEVState structure has cbitpos and reduced_phys_bits fields which are simply copied from the SevGuestState structure and never changed. Now that SEVState is embedded in SevGuestState we can just access the original copy directly. 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-7-david@gibson.dropbear.id.au> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-12target/i386: sev: Partial cleanup to sev_state globalDavid Gibson1-44/+48
The SEV code uses a pretty ugly global to access its internal state. Now that SEVState is embedded in SevGuestState, we can avoid accessing it via the global in some cases. In the remaining cases use a new global referencing the containing SevGuestState which will simplify some future transformations. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200604064219.436242-6-david@gibson.dropbear.id.au> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-12target/i386: sev: Embed SEVState in SevGuestStateDavid Gibson1-25/+29
Currently SevGuestState contains only configuration information. For runtime state another non-QOM struct SEVState is allocated separately. Simplify things by instead embedding the SEVState structure in SevGuestState. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200604064219.436242-5-david@gibson.dropbear.id.au> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-12target/i386: sev: Rename QSevGuestInfoDavid Gibson1-43/+44
At the moment this is a purely passive object which is just a container for information used elsewhere, hence the name. I'm going to change that though, so as a preliminary rename it to SevGuestState. That name risks confusion with both SEVState and SevState, but I'll be working on that in following patches. 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-4-david@gibson.dropbear.id.au> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-12target/i386: sev: Move local structure definitions into .c fileDavid Gibson1-0/+44
Neither QSevGuestInfo nor SEVState (not to be confused with SevState) is used anywhere outside target/i386/sev.c, so they might as well live in there rather than in a (somewhat) exposed header. 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-3-david@gibson.dropbear.id.au> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-12target/i386: sev: Remove unused QSevGuestInfoClassDavid Gibson1-1/+0
This structure is nothing but an empty wrapper around the parent class, which by QOM conventions means we don't need it at all. 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-2-david@gibson.dropbear.id.au> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-05-15qom: Drop parameter @errp of object_property_add() & friendsMarkus Armbruster1-10/+7
The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-15qom: Drop object_property_set_description() parameter @errpMarkus Armbruster1-3/+3
object_property_set_description() and object_class_property_set_description() fail only when property @name is not found. There are 85 calls of object_property_set_description() and object_class_property_set_description(). None of them can fail: * 84 immediately follow the creation of the property. * The one in spapr_rng_instance_init() refers to a property created in spapr_rng_class_init(), from spapr_rng_properties[]. Every one of them still gets to decide what to pass for @errp. 51 calls pass &error_abort, 32 calls pass NULL, one receives the error and propagates it to &error_abort, and one propagates it to &error_fatal. I'm actually surprised none of them violates the Error API. What are we gaining by letting callers handle the "property not found" error? Use when the property is not known to exist is simpler: you don't have to guard the call with a check. We haven't found such a use in 5+ years. Until we do, let's make life a bit simpler and drop the @errp parameter. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-8-armbru@redhat.com> [One semantic rebase conflict resolved]
2020-03-16qom/object: Use common get/set uint helpersFelipe Franciosi1-97/+9
Several objects implemented their own uint property getters and setters, despite them being straightforward (without any checks/validations on the values themselves) and identical across objects. This makes use of an enhanced API for object_property_add_uintXX_ptr() which offers default setters. Some of these setters used to update the value even if the type visit failed (eg. because the value being set overflowed over the given type). The new setter introduces a check for these errors, not updating the value if an error occurred. The error is propagated. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-08-16sysemu: Split sysemu/runstate.h off sysemu/sysemu.hMarkus Armbruster1-0/+1
sysemu/sysemu.h is a rather unfocused dumping ground for stuff related to the system-emulator. Evidence: * It's included widely: in my "build everything" tree, changing sysemu/sysemu.h still triggers a recompile of some 1100 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h, down from 5400 due to the previous two commits). * It pulls in more than a dozen additional headers. Split stuff related to run state management into its own header sysemu/runstate.h. Touching sysemu/sysemu.h now recompiles some 850 objects. qemu/uuid.h also drops from 1100 to 850, and qapi/qapi-types-run-state.h from 4400 to 4200. Touching new sysemu/runstate.h recompiles some 500 objects. Since I'm touching MAINTAINERS to add sysemu/runstate.h anyway, also add qemu/main-loop.h. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-30-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> [Unbreak OS-X build]
2019-07-19target/i386: sev: fix failed message typosJiri Slaby1-2/+2
In these multiline messages, there were typos. Fix them -- add a missing space and remove a superfluous apostrophe. Inspired by Tom's patch. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: qemu-trivial@nongnu.org Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <20190719104118.17735-1-jslaby@suse.cz> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15target/i386: sev: Do not unpin ram device memory regionAlex Williamson1-0/+11
The commit referenced below skipped pinning ram device memory when ram blocks are added, we need to do the same when they're removed. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Fixes: cedc0ad539af ("target/i386: sev: Do not pin the ram device memory region") Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Message-Id: <156320087103.2556.10983987500488190423.stgit@gimli.home> Reviewed-by: Singh, Brijesh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-12Include qemu/module.h where needed, drop it from qemu-common.hMarkus Armbruster1-0/+1
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]
2019-03-18target/i386: sev: Do not pin the ram device memory regionSingh, Brijesh1-0/+11
The RAM device presents a memory region that should be handled as an IO region and should not be pinned. In the case of the vfio-pci, RAM device represents a MMIO BAR and the memory region is not backed by pages hence KVM_MEMORY_ENCRYPT_REG_REGION fails to lock the memory range. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1667249 Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Message-Id: <20190204222322.26766-3-brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-12-20Clean up includesMarkus Armbruster1-1/+2
Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes, with the changes to the following files manually reverted: contrib/libvhost-user/libvhost-user-glib.h contrib/libvhost-user/libvhost-user.c contrib/libvhost-user/libvhost-user.h linux-user/mips64/cpu_loop.c linux-user/mips64/signal.c linux-user/sparc64/cpu_loop.c linux-user/sparc64/signal.c linux-user/x86_64/cpu_loop.c linux-user/x86_64/signal.c target/s390x/gen-features.c tests/migration/s390x/a-b-bios.c tests/test-rcu-simpleq.c tests/test-rcu-tailq.c Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181204172535.2799-1-armbru@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Acked-by: Yuval Shaia <yuval.shaia@oracle.com> Acked-by: Viktor Prutyanov <viktor.prutyanov@phystech.edu>
2018-05-09target/i386: sev: fix memory leaksPaolo Bonzini1-15/+17
Reported by Coverity. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-04-02sev/i386: fix memory leak in sev_guest_init()Greg Kurz1-1/+3
The string returned by object_property_get_str() is dynamically allocated. Fixes: d8575c6c0242b Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <152231462116.69730.14119625999092384450.stgit@bahia.lan> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-03-13sev/i386: add sev_get_capabilities()Brijesh Singh1-0/+83
The function can be used to get the current SEV capabilities. The capabilities include platform diffie-hellman key (pdh) and certificate chain. The key can be provided to the external entities which wants to establish a trusted channel between SEV firmware and guest owner. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-13sev/i386: add migration blockerBrijesh Singh1-0/+13
SEV guest migration is not implemented yet. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-13sev/i386: finalize the SEV guest launch flowBrijesh Singh1-0/+29
SEV launch flow requires us to issue LAUNCH_FINISH command before guest is ready to run. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-13sev/i386: add support to LAUNCH_MEASURE commandBrijesh Singh1-0/+63
During machine creation we encrypted the guest bios image, the LAUNCH_MEASURE command can be used to retrieve the measurement of the encrypted memory region. This measurement is a signature of the memory contents that can be sent to the guest owner as an attestation that the memory was encrypted correctly by the firmware. VM management tools like libvirt can query the measurement using query-sev-launch-measure QMP command. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-13sev/i386: add command to encrypt guest memory regionBrijesh Singh1-0/+43
The KVM_SEV_LAUNCH_UPDATE_DATA command is used to encrypt a guest memory region using the VM Encryption Key created using LAUNCH_START. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-13sev/i386: add command to create launch memory encryption contextBrijesh Singh1-0/+86
The KVM_SEV_LAUNCH_START command creates a new VM encryption key (VEK). The encryption key created with the command will be used for encrypting the bootstrap images (such as guest bios). Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-13sev/i386: register the guest memory range which may contain encrypted dataBrijesh Singh1-0/+42
When SEV is enabled, the hardware encryption engine uses a tweak such that the two identical plaintext at different location will have a different ciphertexts. So swapping or moving a ciphertexts of two guest pages will not result in plaintexts being swapped. Hence relocating a physical backing pages of the SEV guest will require some additional steps in KVM driver. The KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl can be used to register/unregister the guest memory region which may contain the encrypted data. KVM driver will internally handle the relocating physical backing pages of registered memory regions. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-13sev/i386: add command to initialize the memory encryption contextBrijesh Singh1-0/+224
When memory encryption is enabled, KVM_SEV_INIT command is used to initialize the platform. The command loads the SEV related persistent data from non-volatile storage and initializes the platform context. This command should be first issued before invoking any other guest commands provided by the SEV firmware. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-13target/i386: add Secure Encrypted Virtualization (SEV) objectBrijesh Singh1-0/+228
Add a new memory encryption object 'sev-guest'. The object will be used to create encrypted VMs on AMD EPYC CPU. The object provides the properties to pass guest owner's public Diffie-hellman key, guest policy and session information required to create the memory encryption context within the SEV firmware. e.g to launch SEV guest # $QEMU \ -object sev-guest,id=sev0 \ -machine ....,memory-encryption=sev0 Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.1 at 2025-01-27 08:44:21 +0000