mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-08-02 15:23:53 -06:00
ppc-7.0 queue
* Exception model rework (Fabiano) * Unused CPU models removal (Fabiano and Cédric) * Fix for VOF installation (Alexey) * Misc fixes -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmIFDBsACgkQUaNDx8/7 7KHmmg//RjCaqbubw8nc58stxGvwf30tcLzPKbQzoz4rZ/hxMaXDKTzh7BA16qJO fJDrnQCcYa1dpLWXCygY/5G7+DbaGYRava/3BqBv2qAO0wDdKbnxKGuFSSbqgeca skTQK1R5hSYclFNI13yFLJrAkwiTSZjI+UhCkUqW6wZS1qeZ1ClBwoCMIZ8dP4vE cshD78lFRSCLhScrhhQqeQymEWk6eUmv4TY2gSiVpCZCaR1wlXxy3/YOd5i2w2B1 A+JAwvCOknKaGzCftbZN0Po8orcdXyQ96YZNQxjL9Wu58zZllqzolF2pJi0Qph2h 3ZW7Bw3BbnUl6ceWg/J/e+gVkGLKyPGJ6eD556HxccJZPXgtEC8QyP8ACzl3mJ1E 13abW4yX7XwtgmVoXQQu0vaKKM4AamIkqYgn/kGP1TQO5s+CMf61+WYy1HzIio1Z 9jUhpRWBiEsuhigy/kFejU9dYVHYJ0rcr7pwRa+Nhet+8Rzv5Klr6rQExsftkZmc 0KcJDhpGVrmdO/qU8BYh/lhyOvx9+9qI8gG/g2PJtR4VSTHRUqxZ+VzuIC2tVpD0 XJnCNSBgJs59kybPX3Pn1f8BmVoZBq+oJBScrOJne3finBbxioo4JiKReBD12y1A LxE+JTV0N/aPjkMzuw+VXPMZ1suxrd2doiyDKXv/eijleGtdsPg= =/0n8 -----END PGP SIGNATURE----- Merge remote-tracking branch 'remotes/legoater/tags/pull-ppc-20220210' into staging ppc-7.0 queue * Exception model rework (Fabiano) * Unused CPU models removal (Fabiano and Cédric) * Fix for VOF installation (Alexey) * Misc fixes # gpg: Signature made Thu 10 Feb 2022 12:59:07 GMT # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * remotes/legoater/tags/pull-ppc-20220210: (42 commits) spapr/vof: Install rom and nvram binaries docs: rstfy confidential guest documentation target/ppc: Change VSX instructions behavior to fill with zeros target/ppc: books: Remove excp_model argument from ppc_excp_apply_ail target/ppc: Assert if MSR bits differ from msr_mask during exceptions target/ppc: powerpc_excp: Move common code to the caller function target/ppc: Remove powerpc_excp_legacy target/ppc: 7xx: Set SRRs directly in exception code target/ppc: 7xx: Software TLB cleanup target/ppc: 7xx: System Reset cleanup target/ppc: 7xx: System Call exception cleanup target/ppc: 7xx: Program exception cleanup target/ppc: 7xx: External interrupt cleanup target/ppc: 7xx: Machine Check exception cleanup target/ppc: Simplify powerpc_excp_7xx target/ppc: Introduce powerpc_excp_7xx target/ppc: Merge 7x5 and 7x0 exception model IDs target/ppc: 6xx: Set SRRs directly in exception code target/ppc: 6xx: Software TLB exceptions cleanup target/ppc: 6xx: System Reset interrupt cleanup ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This commit is contained in:
Peter Maydell
commit
cc5ce8b8b6
32 changed files with 717 additions and 2375 deletions
|
|
@ -19,10 +19,10 @@ Running a Confidential Guest
|
|||
|
||||
To run a confidential guest you need to add two command line parameters:
|
||||
|
||||
1. Use "-object" to create a "confidential guest support" object. The
|
||||
1. Use ``-object`` to create a "confidential guest support" object. The
|
||||
type and parameters will vary with the specific mechanism to be
|
||||
used
|
||||
2. Set the "confidential-guest-support" machine parameter to the ID of
|
||||
2. Set the ``confidential-guest-support`` machine parameter to the ID of
|
||||
the object from (1).
|
||||
|
||||
Example (for AMD SEV)::
|
||||
|
|
@ -37,13 +37,8 @@ Supported mechanisms
|
|||
|
||||
Currently supported confidential guest mechanisms are:
|
||||
|
||||
AMD Secure Encrypted Virtualization (SEV)
|
||||
docs/amd-memory-encryption.txt
|
||||
|
||||
POWER Protected Execution Facility (PEF)
|
||||
docs/papr-pef.txt
|
||||
|
||||
s390x Protected Virtualization (PV)
|
||||
docs/system/s390x/protvirt.rst
|
||||
* AMD Secure Encrypted Virtualization (SEV) (see :doc:`i386/amd-memory-encryption`)
|
||||
* POWER Protected Execution Facility (PEF) (see :ref:`power-papr-protected-execution-facility-pef`)
|
||||
* s390x Protected Virtualization (PV) (see :doc:`s390x/protvirt`)
|
||||
|
||||
Other mechanisms may be supported in future.
|
||||
|
|
@ -1,3 +1,6 @@
|
|||
AMD Secure Encrypted Virtualization (SEV)
|
||||
=========================================
|
||||
|
||||
Secure Encrypted Virtualization (SEV) is a feature found on AMD processors.
|
||||
|
||||
SEV is an extension to the AMD-V architecture which supports running encrypted
|
||||
|
|
@ -24,17 +27,18 @@ the hypervisor to satisfy the requested function.
|
|||
|
||||
Launching
|
||||
---------
|
||||
|
||||
Boot images (such as bios) must be encrypted before a guest can be booted. The
|
||||
MEMORY_ENCRYPT_OP ioctl provides commands to encrypt the images: LAUNCH_START,
|
||||
LAUNCH_UPDATE_DATA, LAUNCH_MEASURE and LAUNCH_FINISH. These four commands
|
||||
``MEMORY_ENCRYPT_OP`` ioctl provides commands to encrypt the images: ``LAUNCH_START``,
|
||||
``LAUNCH_UPDATE_DATA``, ``LAUNCH_MEASURE`` and ``LAUNCH_FINISH``. These four commands
|
||||
together generate a fresh memory encryption key for the VM, encrypt the boot
|
||||
images and provide a measurement than can be used as an attestation of a
|
||||
successful launch.
|
||||
|
||||
For a SEV-ES guest, the LAUNCH_UPDATE_VMSA command is also used to encrypt the
|
||||
For a SEV-ES guest, the ``LAUNCH_UPDATE_VMSA`` command is also used to encrypt the
|
||||
guest register state, or VM save area (VMSA), for all of the guest vCPUs.
|
||||
|
||||
LAUNCH_START is called first to create a cryptographic launch context within
|
||||
``LAUNCH_START`` is called first to create a cryptographic launch context within
|
||||
the firmware. To create this context, guest owner must provide a guest policy,
|
||||
its public Diffie-Hellman key (PDH) and session parameters. These inputs
|
||||
should be treated as a binary blob and must be passed as-is to the SEV firmware.
|
||||
|
|
@ -45,37 +49,37 @@ in bad measurement). The guest policy is a 4-byte data structure containing
|
|||
several flags that restricts what can be done on a running SEV guest.
|
||||
See KM Spec section 3 and 6.2 for more details.
|
||||
|
||||
The guest policy can be provided via the 'policy' property (see below)
|
||||
The guest policy can be provided via the ``policy`` property::
|
||||
|
||||
# ${QEMU} \
|
||||
sev-guest,id=sev0,policy=0x1...\
|
||||
# ${QEMU} \
|
||||
sev-guest,id=sev0,policy=0x1...\
|
||||
|
||||
Setting the "SEV-ES required" policy bit (bit 2) will launch the guest as a
|
||||
SEV-ES guest (see below)
|
||||
SEV-ES guest::
|
||||
|
||||
# ${QEMU} \
|
||||
sev-guest,id=sev0,policy=0x5...\
|
||||
# ${QEMU} \
|
||||
sev-guest,id=sev0,policy=0x5...\
|
||||
|
||||
The guest owner provided DH certificate and session parameters will be used to
|
||||
establish a cryptographic session with the guest owner to negotiate keys used
|
||||
for the attestation.
|
||||
|
||||
The DH certificate and session blob can be provided via the 'dh-cert-file' and
|
||||
'session-file' properties (see below)
|
||||
The DH certificate and session blob can be provided via the ``dh-cert-file`` and
|
||||
``session-file`` properties::
|
||||
|
||||
# ${QEMU} \
|
||||
sev-guest,id=sev0,dh-cert-file=<file1>,session-file=<file2>
|
||||
# ${QEMU} \
|
||||
sev-guest,id=sev0,dh-cert-file=<file1>,session-file=<file2>
|
||||
|
||||
LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context
|
||||
created via the LAUNCH_START command. If required, this command can be called
|
||||
``LAUNCH_UPDATE_DATA`` encrypts the memory region using the cryptographic context
|
||||
created via the ``LAUNCH_START`` command. If required, this command can be called
|
||||
multiple times to encrypt different memory regions. The command also calculates
|
||||
the measurement of the memory contents as it encrypts.
|
||||
|
||||
LAUNCH_UPDATE_VMSA encrypts all the vCPU VMSAs for a SEV-ES guest using the
|
||||
cryptographic context created via the LAUNCH_START command. The command also
|
||||
``LAUNCH_UPDATE_VMSA`` encrypts all the vCPU VMSAs for a SEV-ES guest using the
|
||||
cryptographic context created via the ``LAUNCH_START`` command. The command also
|
||||
calculates the measurement of the VMSAs as it encrypts them.
|
||||
|
||||
LAUNCH_MEASURE can be used to retrieve the measurement of encrypted memory and,
|
||||
``LAUNCH_MEASURE`` can be used to retrieve the measurement of encrypted memory and,
|
||||
for a SEV-ES guest, encrypted VMSAs. This measurement is a signature of the
|
||||
memory contents and, for a SEV-ES guest, the VMSA contents, that can be sent
|
||||
to the guest owner as an attestation that the memory and VMSAs were encrypted
|
||||
|
|
@ -85,27 +89,28 @@ Since the guest owner knows the initial contents of the guest at boot, the
|
|||
attestation measurement can be verified by comparing it to what the guest owner
|
||||
expects.
|
||||
|
||||
LAUNCH_FINISH finalizes the guest launch and destroys the cryptographic
|
||||
``LAUNCH_FINISH`` finalizes the guest launch and destroys the cryptographic
|
||||
context.
|
||||
|
||||
See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the
|
||||
See SEV KM API Spec ([SEVKM]_) 'Launching a guest' usage flow (Appendix A) for the
|
||||
complete flow chart.
|
||||
|
||||
To launch a SEV guest
|
||||
To launch a SEV guest::
|
||||
|
||||
# ${QEMU} \
|
||||
-machine ...,confidential-guest-support=sev0 \
|
||||
-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
|
||||
# ${QEMU} \
|
||||
-machine ...,confidential-guest-support=sev0 \
|
||||
-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
|
||||
|
||||
To launch a SEV-ES guest
|
||||
To launch a SEV-ES guest::
|
||||
|
||||
# ${QEMU} \
|
||||
-machine ...,confidential-guest-support=sev0 \
|
||||
-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x5
|
||||
# ${QEMU} \
|
||||
-machine ...,confidential-guest-support=sev0 \
|
||||
-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x5
|
||||
|
||||
An SEV-ES guest has some restrictions as compared to a SEV guest. Because the
|
||||
guest register state is encrypted and cannot be updated by the VMM/hypervisor,
|
||||
a SEV-ES guest:
|
||||
|
||||
- Does not support SMM - SMM support requires updating the guest register
|
||||
state.
|
||||
- Does not support reboot - a system reset requires updating the guest register
|
||||
|
|
@ -114,35 +119,42 @@ a SEV-ES guest:
|
|||
manage booting APs.
|
||||
|
||||
Debugging
|
||||
-----------
|
||||
---------
|
||||
|
||||
Since the memory contents of a SEV guest are encrypted, hypervisor access to
|
||||
the guest memory will return cipher text. If the guest policy allows debugging,
|
||||
then a hypervisor can use the DEBUG_DECRYPT and DEBUG_ENCRYPT commands to access
|
||||
the guest memory region for debug purposes. This is not supported in QEMU yet.
|
||||
|
||||
Snapshot/Restore
|
||||
-----------------
|
||||
----------------
|
||||
|
||||
TODO
|
||||
|
||||
Live Migration
|
||||
----------------
|
||||
---------------
|
||||
|
||||
TODO
|
||||
|
||||
References
|
||||
-----------------
|
||||
----------
|
||||
|
||||
AMD Memory Encryption whitepaper:
|
||||
https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
|
||||
`AMD Memory Encryption whitepaper
|
||||
<https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf>`_
|
||||
|
||||
Secure Encrypted Virtualization Key Management:
|
||||
[1] http://developer.amd.com/wordpress/media/2017/11/55766_SEV-KM-API_Specification.pdf
|
||||
.. [SEVKM] `Secure Encrypted Virtualization Key Management
|
||||
<http://developer.amd.com/wordpress/media/2017/11/55766_SEV-KM-API_Specification.pdf>`_
|
||||
|
||||
KVM Forum slides:
|
||||
http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
|
||||
https://www.linux-kvm.org/images/9/94/Extending-Secure-Encrypted-Virtualization-with-SEV-ES-Thomas-Lendacky-AMD.pdf
|
||||
|
||||
AMD64 Architecture Programmer's Manual:
|
||||
http://support.amd.com/TechDocs/24593.pdf
|
||||
SME is section 7.10
|
||||
SEV is section 15.34
|
||||
SEV-ES is section 15.35
|
||||
* `AMD’s Virtualization Memory Encryption (2016)
|
||||
<http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf>`_
|
||||
* `Extending Secure Encrypted Virtualization With SEV-ES (2018)
|
||||
<https://www.linux-kvm.org/images/9/94/Extending-Secure-Encrypted-Virtualization-with-SEV-ES-Thomas-Lendacky-AMD.pdf>`_
|
||||
|
||||
`AMD64 Architecture Programmer's Manual:
|
||||
<http://support.amd.com/TechDocs/24593.pdf>`_
|
||||
|
||||
* SME is section 7.10
|
||||
* SEV is section 15.34
|
||||
* SEV-ES is section 15.35
|
||||
|
|
@ -34,3 +34,4 @@ or Hypervisor.Framework.
|
|||
targets
|
||||
security
|
||||
multi-process
|
||||
confidential-guest-support
|
||||
|
|
|
|||
|
|
@ -224,6 +224,8 @@ nested. Combinations not shown in the table are not available.
|
|||
.. [3] Introduced on Power10 machines.
|
||||
|
||||
|
||||
.. _power-papr-protected-execution-facility-pef:
|
||||
|
||||
POWER (PAPR) Protected Execution Facility (PEF)
|
||||
-----------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -28,6 +28,7 @@ Architectural features
|
|||
i386/cpu
|
||||
i386/kvm-pv
|
||||
i386/sgx
|
||||
i386/amd-memory-encryption
|
||||
|
||||
.. _pcsys_005freq:
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue