aboutsummaryrefslogtreecommitdiff
path: root/target/i386/sev.c
AgeCommit message (Collapse)AuthorFilesLines
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 2024-10-01 02:55:37 +0000