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