motorhead/qemu
1
0
Fork 0
mirror of https://github.com/Motorhead1991/qemu.git synced 2025-08-18 23:52:14 -06:00
Code Issues Projects Releases Packages Wiki Activity Actions

* SGX implementation for x86

Browse source 
* Miscellaneous bugfixes
 * Fix dependencies from ROMs to qtests
 -----BEGIN PGP SIGNATURE-----
 
 iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmFVu/sUHHBib256aW5p
 QHJlZGhhdC5jb20ACgkQv/vSX3jHroNFUgf+OexjKqJw4qzbDdQrxWqw3upoFblk
 y4OrmrhCyCKDwPghnjHUEVGHnNKqKpCLoIvtvFZ7xX/qezpMtZxVUliOVNQGmioR
 MZU/DbdlvVL/t8yKjfz1ljshk55hnSJ7rAv8LBA+B3uNzyJ+LZU9+Kbvmei5oyex
 nenCtXnoVNBJMvTBE/KfJbp0UasEb1OTvPBa0Y7mHyDub28FDPKr9WZbloCLUtE+
 uXwbZ34VRDsxbLnXh+BJ+ljOQLdsJErAkiPKTnW1/3W8Ti7PzOzvLpbSIVdBv/9A
 U1qOEm48BjCrG/tFJvTUm0ZM7AHmqYfvmwpenDpL0FhReohMdUa3pycQ9g==
 =Hicy
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into staging

* SGX implementation for x86
* Miscellaneous bugfixes
* Fix dependencies from ROMs to qtests

# gpg: Signature made Thu 30 Sep 2021 14:30:35 BST
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
#      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83

* remotes/bonzini-gitlab/tags/for-upstream: (33 commits)
  meson_options.txt: Switch the default value for the vnc option to 'auto'
  build-sys: add HAVE_IPPROTO_MPTCP
  memory: Add tracepoint for dirty sync
  memory: Name all the memory listeners
  target/i386: Fix memory leak in sev_read_file_base64()
  tests: qtest: bios-tables-test depends on the unpacked edk2 ROMs
  meson: unpack edk2 firmware even if --disable-blobs
  target/i386: Add the query-sgx-capabilities QMP command
  target/i386: Add HMP and QMP interfaces for SGX
  docs/system: Add SGX documentation to the system manual
  sgx-epc: Add the fill_device_info() callback support
  i440fx: Add support for SGX EPC
  q35: Add support for SGX EPC
  i386: acpi: Add SGX EPC entry to ACPI tables
  i386/pc: Add e820 entry for SGX EPC section(s)
  hw/i386/pc: Account for SGX EPC sections when calculating device memory
  hw/i386/fw_cfg: Set SGX bits in feature control fw_cfg accordingly
  Adjust min CPUID level to 0x12 when SGX is enabled
  i386: Propagate SGX CPUID sub-leafs to KVM
  i386: kvm: Add support for exposing PROVISIONKEY to guest
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This commit is contained in:
Peter Maydell 2021-09-30 17:38:30 +01:00
commit 0021c4765a
64 changed files with 1397 additions and 38 deletions
Download patch file Download diff file Expand all files Collapse all files

165
docs/system/i386/sgx.rst Normal file
View file

@ -0,0 +1,165 @@
Software Guard eXtensions (SGX)
===============================
Overview
--------
Intel Software Guard eXtensions (SGX) is a set of instructions and mechanisms
for memory accesses in order to provide security accesses for sensitive
applications and data. SGX allows an application to use it's pariticular
address space as an *enclave*, which is a protected area provides confidentiality
and integrity even in the presence of privileged malware. Accesses to the
enclave memory area from any software not resident in the enclave are prevented,
including those from privileged software.
Virtual SGX
-----------
SGX feature is exposed to guest via SGX CPUID. Looking at SGX CPUID, we can
report the same CPUID info to guest as on host for most of SGX CPUID. With
reporting the same CPUID guest is able to use full capacity of SGX, and KVM
doesn't need to emulate those info.
The guest's EPC base and size are determined by Qemu, and KVM needs Qemu to
notify such info to it before it can initialize SGX for guest.
Virtual EPC
~~~~~~~~~~~
By default, Qemu does not assign EPC to a VM, i.e. fully enabling SGX in a VM
requires explicit allocation of EPC to the VM. Similar to other specialized
memory types, e.g. hugetlbfs, EPC is exposed as a memory backend.
SGX EPC is enumerated through CPUID, i.e. EPC "devices" need to be realized
prior to realizing the vCPUs themselves, which occurs long before generic
devices are parsed and realized. This limitation means that EPC does not
require -maxmem as EPC is not treated as {cold,hot}plugged memory.
Qemu does not artificially restrict the number of EPC sections exposed to a
guest, e.g. Qemu will happily allow you to create 64 1M EPC sections. Be aware
that some kernels may not recognize all EPC sections, e.g. the Linux SGX driver
is hardwired to support only 8 EPC sections.
The following Qemu snippet creates two EPC sections, with 64M pre-allocated
to the VM and an additional 28M mapped but not allocated::
-object memory-backend-epc,id=mem1,size=64M,prealloc=on \
-object memory-backend-epc,id=mem2,size=28M \
-M sgx-epc.0.memdev=mem1,sgx-epc.1.memdev=mem2
Note:
The size and location of the virtual EPC are far less restricted compared
to physical EPC. Because physical EPC is protected via range registers,
the size of the physical EPC must be a power of two (though software sees
a subset of the full EPC, e.g. 92M or 128M) and the EPC must be naturally
aligned. KVM SGX's virtual EPC is purely a software construct and only
requires the size and location to be page aligned. Qemu enforces the EPC
size is a multiple of 4k and will ensure the base of the EPC is 4k aligned.
To simplify the implementation, EPC is always located above 4g in the guest
physical address space.
Migration
~~~~~~~~~
Qemu/KVM doesn't prevent live migrating SGX VMs, although from hardware's
perspective, SGX doesn't support live migration, since both EPC and the SGX
key hierarchy are bound to the physical platform. However live migration
can be supported in the sense if guest software stack can support recreating
enclaves when it suffers sudden lose of EPC; and if guest enclaves can detect
SGX keys being changed, and handle gracefully. For instance, when ERESUME fails
with #PF.SGX, guest software can gracefully detect it and recreate enclaves;
and when enclave fails to unseal sensitive information from outside, it can
detect such error and sensitive information can be provisioned to it again.
CPUID
~~~~~
Due to its myriad dependencies, SGX is currently not listed as supported
in any of Qemu's built-in CPU configuration. To expose SGX (and SGX Launch
Control) to a guest, you must either use `-cpu host` to pass-through the
host CPU model, or explicitly enable SGX when using a built-in CPU model,
e.g. via `-cpu <model>,+sgx` or `-cpu <model>,+sgx,+sgxlc`.
All SGX sub-features enumerated through CPUID, e.g. SGX2, MISCSELECT,
ATTRIBUTES, etc... can be restricted via CPUID flags. Be aware that enforcing
restriction of MISCSELECT, ATTRIBUTES and XFRM requires intercepting ECREATE,
i.e. may marginally reduce SGX performance in the guest. All SGX sub-features
controlled via -cpu are prefixed with "sgx", e.g.::
$ qemu-system-x86_64 -cpu help | xargs printf "%s\n" | grep sgx
sgx
sgx-debug
sgx-encls-c
sgx-enclv
sgx-exinfo
sgx-kss
sgx-mode64
sgx-provisionkey
sgx-tokenkey
sgx1
sgx2
sgxlc
The following Qemu snippet passes through the host CPU but restricts access to
the provision and EINIT token keys::
-cpu host,-sgx-provisionkey,-sgx-tokenkey
SGX sub-features cannot be emulated, i.e. sub-features that are not present
in hardware cannot be forced on via '-cpu'.
Virtualize SGX Launch Control
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Qemu SGX support for Launch Control (LC) is passive, in the sense that it
does not actively change the LC configuration. Qemu SGX provides the user
the ability to set/clear the CPUID flag (and by extension the associated
IA32_FEATURE_CONTROL MSR bit in fw_cfg) and saves/restores the LE Hash MSRs
when getting/putting guest state, but Qemu does not add new controls to
directly modify the LC configuration. Similar to hardware behavior, locking
the LC configuration to a non-Intel value is left to guest firmware. Unlike
host bios setting for SGX launch control(LC), there is no special bios setting
for SGX guest by our design. If host is in locked mode, we can still allow
creating VM with SGX.
Feature Control
~~~~~~~~~~~~~~~
Qemu SGX updates the `etc/msr_feature_control` fw_cfg entry to set the SGX
(bit 18) and SGX LC (bit 17) flags based on their respective CPUID support,
i.e. existing guest firmware will automatically set SGX and SGX LC accordingly,
assuming said firmware supports fw_cfg.msr_feature_control.
Launching a guest
-----------------
To launch a SGX guest:
.. parsed-literal::
|qemu_system_x86| \\
-cpu host,+sgx-provisionkey \\
-object memory-backend-epc,id=mem1,size=64M,prealloc=on \\
-object memory-backend-epc,id=mem2,size=28M \\
-M sgx-epc.0.memdev=mem1,sgx-epc.1.memdev=mem2
Utilizing SGX in the guest requires a kernel/OS with SGX support.
The support can be determined in guest by::
$ grep sgx /proc/cpuinfo
and SGX epc info by::
$ dmesg | grep sgx
[ 1.242142] sgx: EPC section 0x180000000-0x181bfffff
[ 1.242319] sgx: EPC section 0x181c00000-0x1837fffff
References
----------
- `SGX Homepage <https://software.intel.com/sgx>`__
- `SGX SDK <https://github.com/intel/linux-sgx.git>`__
- SGX specification: Intel SDM Volume 3

1
docs/system/target-i386.rst
View file

@ -26,6 +26,7 @@ Architectural features
:maxdepth: 1
i386/cpu
i386/sgx
.. _pcsys_005freq: