s390-pv-boot.rst 3.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384
  1. .. SPDX-License-Identifier: GPL-2.0
  2. ======================================
  3. s390 (IBM Z) Boot/IPL of Protected VMs
  4. ======================================
  5. Summary
  6. -------
  7. The memory of Protected Virtual Machines (PVMs) is not accessible to
  8. I/O or the hypervisor. In those cases where the hypervisor needs to
  9. access the memory of a PVM, that memory must be made accessible.
  10. Memory made accessible to the hypervisor will be encrypted. See
  11. Documentation/virt/kvm/s390/s390-pv.rst for details."
  12. On IPL (boot) a small plaintext bootloader is started, which provides
  13. information about the encrypted components and necessary metadata to
  14. KVM to decrypt the protected virtual machine.
  15. Based on this data, KVM will make the protected virtual machine known
  16. to the Ultravisor (UV) and instruct it to secure the memory of the
  17. PVM, decrypt the components and verify the data and address list
  18. hashes, to ensure integrity. Afterwards KVM can run the PVM via the
  19. SIE instruction which the UV will intercept and execute on KVM's
  20. behalf.
  21. As the guest image is just like an opaque kernel image that does the
  22. switch into PV mode itself, the user can load encrypted guest
  23. executables and data via every available method (network, dasd, scsi,
  24. direct kernel, ...) without the need to change the boot process.
  25. Diag308
  26. -------
  27. This diagnose instruction is the basic mechanism to handle IPL and
  28. related operations for virtual machines. The VM can set and retrieve
  29. IPL information blocks, that specify the IPL method/devices and
  30. request VM memory and subsystem resets, as well as IPLs.
  31. For PVMs this concept has been extended with new subcodes:
  32. Subcode 8: Set an IPL Information Block of type 5 (information block
  33. for PVMs)
  34. Subcode 9: Store the saved block in guest memory
  35. Subcode 10: Move into Protected Virtualization mode
  36. The new PV load-device-specific-parameters field specifies all data
  37. that is necessary to move into PV mode.
  38. * PV Header origin
  39. * PV Header length
  40. * List of Components composed of
  41. * AES-XTS Tweak prefix
  42. * Origin
  43. * Size
  44. The PV header contains the keys and hashes, which the UV will use to
  45. decrypt and verify the PV, as well as control flags and a start PSW.
  46. The components are for instance an encrypted kernel, kernel parameters
  47. and initrd. The components are decrypted by the UV.
  48. After the initial import of the encrypted data, all defined pages will
  49. contain the guest content. All non-specified pages will start out as
  50. zero pages on first access.
  51. When running in protected virtualization mode, some subcodes will result in
  52. exceptions or return error codes.
  53. Subcodes 4 and 7, which specify operations that do not clear the guest
  54. memory, will result in specification exceptions. This is because the
  55. UV will clear all memory when a secure VM is removed, and therefore
  56. non-clearing IPL subcodes are not allowed.
  57. Subcodes 8, 9, 10 will result in specification exceptions.
  58. Re-IPL into a protected mode is only possible via a detour into non
  59. protected mode.
  60. Keys
  61. ----
  62. Every CEC will have a unique public key to enable tooling to build
  63. encrypted images.
  64. See `s390-tools <https://github.com/ibm-s390-linux/s390-tools/>`_
  65. for the tooling.