[SRU][J][PULL] KVM: Secure Execution guest dump encryption with customer keys

frank.heimes at canonical.com frank.heimes at canonical.com
Fri Aug 30 09:34:36 UTC 2024


BugLink: https://bugs.launchpad.net/bugs/1959940

[ Impact ]

 * Hypervisor-initiated dumps for Secure Execution
   (aka confidential computing) guests are not helpful,
   because memory and CPU state is encrypted by a
   transient key only available to the Ultravisor (uv).

 * Workload owners can still configure kdump in order to obtain kernel
   crash information, but there are situation where kdump doesn't work.

 * In such situations problem determination is severely impeded.

 * This patch set solves this by implementing dumps created in a way
   that can only be decrypted by the owner of the guest image
   and be used for problem determination.

[ Test Plan ]

 * The setup of a Secure Execution environment is not trivial
   and requires a certain set of hardware (IBM z15 or higher)
   with FC 115).

 * On top of the modification of qemu that are handled in this
   LP bug, modifications of the Kernel (LP#1959940) and
   the s390-tools (LP#1959965) are required on top.

 * So at least a modified kernel and qemu test builds are needed
   or both should be in -proposed at the same time (which might
   be difficult).
   A modified s390-tools is not urgently needed, since for the
   verification of the kernel and qemu part a newer version
   can be used (but a modified s390-tools is also available in PPA).

 * A detailed description (using Ubuntu as example) on how to setup
   secure execution is available here:
   Introducing IBM Secure Execution for Linux, April 2024 update
   https://www.ibm.com/docs/en/linuxonibm/pdf/lx24se04.pdf

 * And information on 'Working with dumps of KVM guests in
   IBM Secure Execution mode' is available here:
   https://www.ibm.com/docs/en/linux-on-systems\
   ?topic=commands-zgetdump#czgetdump__se_dump_examples

[ Where problems could occur ]

 * Ultravisor (uv) return codes are introduced, which is
   generally appreciated. Just the right return codes need to be set
   (and reacted upon).

 * Protected virtual machine dumps are newly introduced on top of
   dump of 'normal' KVM VMs.
   Since code is shared, it could have an unforeseen impact.

 * The doc renaming could lead to confusion,
   if people rely on old doc structure.

 * The new capability case (217) could cause issues,
   for example is case of issues during initialization..
 
 * CPU dump functionality was added (mainly as new s390x specific code
   under s390/kvm), but CPU dump is only one part,
   if not working correctly, it may lead to partially useless dump data.

 * Configuration dump functionality was also added
   (again mainly as new s390x specific code under s390/kvm),
   similar to CPU dump.
   And moving from dumping inside of a VM to dumping from outside
   (due to potential failures if done inside), might lead to a more
   complex flow (now involving the uv), hence could be more error prone.

 * Adding query dump information, requires user space buffers.
   Here it's crucial that buffer size is big enough.

 * The newly added constants and structure definitions that are
   needed for dump support could become problematic in case wrong
   data types were used (applies to all header modifications).

 * IOCTL for PV information retrieval got introduced
   (kvm_s390_handle_pv_info, kvm_s390_handle_pv).
   There are potential side effect (see man ioctl),
   hence all potential failure cases should be covered.

 * New dump feature requires to know how much memory is needed, but if
   this call for this is incorrect, it could break the dump process.

 * uv_cb_header struct changed to offset representation,
   but using wrong offsets will lead to a wrong struct,
   dump issues and potential crashes.

[ Other Info ]

 * Since 22.04 is a popular LTS release, it is already in use by many
   secure execution customers.
   But in case of severe crashes or issues in the secure execution
   (KVM) guests dumps cannot be used as of today.

 * This enables customers, IBM and Canonical to get support in case of
   crashes/dumps on hardware that runs secure execution environments.

The following changes since commit 26e0f85b437d70d39acea1321f64dffe6608319d:

  UBUNTU: Upstream stable to v5.15.162 (2024-07-26 11:56:43 +0200)

are available in the Git repository at:

  https://git.launchpad.net/~fheimes/+git/lp1959940j/ 0d574dbec328ae55aea03cf010e4998b02dda47f

for you to fetch changes up to 0d574dbec328ae55aea03cf010e4998b02dda47f:

  Documentation/virt/kvm/api.rst: Explain rc/rrc delivery (2024-08-29 08:35:21 +0200)

----------------------------------------------------------------
Janosch Frank (12):
      s390: uv: Add offset comments to UV query struct and fix naming
      s390/uv: Add SE hdr query information
      s390/uv: Add dump fields to query
      KVM: s390: pv: Add query interface
      KVM: s390: pv: Add dump support definitions
      KVM: s390: pv: Add query dump information
      KVM: s390: Add configuration dump functionality
      KVM: s390: Add CPU dump functionality
      KVM: s390: Add KVM_CAP_S390_PROTECTED_DUMP
      Documentation: virt: Protected virtual machine dumps
      Documentation/virt/kvm/api.rst: Add protvirt dump/info api descriptions
      Documentation/virt/kvm/api.rst: Explain rc/rrc delivery

Paolo Bonzini (1):
      Documentation: KVM: add separate directories for architecture-specific documentation

 Documentation/virt/kvm/api.rst                     | 161 +++++++++++-
 Documentation/virt/kvm/index.rst                   |  26 +-
 Documentation/virt/kvm/s390/index.rst              |  13 +
 Documentation/virt/kvm/{ => s390}/s390-diag.rst    |   0
 Documentation/virt/kvm/{ => s390}/s390-pv-boot.rst |   0
 Documentation/virt/kvm/s390/s390-pv-dump.rst       |  64 +++++
 Documentation/virt/kvm/{ => s390}/s390-pv.rst      |   0
 .../virt/kvm/{ => x86}/amd-memory-encryption.rst   |   0
 Documentation/virt/kvm/{ => x86}/cpuid.rst         |   0
 Documentation/virt/kvm/{ => x86}/halt-polling.rst  |   0
 Documentation/virt/kvm/{ => x86}/hypercalls.rst    |   0
 Documentation/virt/kvm/x86/index.rst               |  18 ++
 Documentation/virt/kvm/{ => x86}/mmu.rst           |   0
 Documentation/virt/kvm/{ => x86}/msr.rst           |   0
 Documentation/virt/kvm/{ => x86}/nested-vmx.rst    |   0
 .../virt/kvm/{ => x86}/running-nested-guests.rst   |   0
 Documentation/virt/kvm/{ => x86}/timekeeping.rst   |   0
 arch/s390/boot/uv.c                                |   4 +
 arch/s390/include/asm/kvm_host.h                   |   1 +
 arch/s390/include/asm/uv.h                         |  77 ++++--
 arch/s390/kernel/uv.c                              |  53 ++++
 arch/s390/kvm/kvm-s390.c                           | 269 +++++++++++++++++++++
 arch/s390/kvm/kvm-s390.h                           |   5 +
 arch/s390/kvm/pv.c                                 | 198 +++++++++++++++
 include/uapi/linux/kvm.h                           |  55 +++++
 25 files changed, 906 insertions(+), 38 deletions(-)
 create mode 100644 Documentation/virt/kvm/s390/index.rst
 rename Documentation/virt/kvm/{ => s390}/s390-diag.rst (100%)
 rename Documentation/virt/kvm/{ => s390}/s390-pv-boot.rst (100%)
 create mode 100644 Documentation/virt/kvm/s390/s390-pv-dump.rst
 rename Documentation/virt/kvm/{ => s390}/s390-pv.rst (100%)
 rename Documentation/virt/kvm/{ => x86}/amd-memory-encryption.rst (100%)
 rename Documentation/virt/kvm/{ => x86}/cpuid.rst (100%)
 rename Documentation/virt/kvm/{ => x86}/halt-polling.rst (100%)
 rename Documentation/virt/kvm/{ => x86}/hypercalls.rst (100%)
 create mode 100644 Documentation/virt/kvm/x86/index.rst
 rename Documentation/virt/kvm/{ => x86}/mmu.rst (100%)
 rename Documentation/virt/kvm/{ => x86}/msr.rst (100%)
 rename Documentation/virt/kvm/{ => x86}/nested-vmx.rst (100%)
 rename Documentation/virt/kvm/{ => x86}/running-nested-guests.rst (100%)
 rename Documentation/virt/kvm/{ => x86}/timekeeping.rst (100%)



More information about the kernel-team mailing list