On 11/6/19 5:48 PM, Cornelia Huck wrote: > On Thu, 24 Oct 2019 07:40:52 -0400 > Janosch Frank <frankja@xxxxxxxxxxxxx> wrote: > >> Description of changes that are necessary to move a KVM VM into >> Protected Virtualization mode. >> >> Signed-off-by: Janosch Frank <frankja@xxxxxxxxxxxxx> >> --- >> Documentation/virtual/kvm/s390-pv-boot.txt | 62 ++++++++++++++++++++++ >> 1 file changed, 62 insertions(+) >> create mode 100644 Documentation/virtual/kvm/s390-pv-boot.txt >> >> diff --git a/Documentation/virtual/kvm/s390-pv-boot.txt b/Documentation/virtual/kvm/s390-pv-boot.txt >> new file mode 100644 >> index 000000000000..af883c928c08 >> --- /dev/null >> +++ b/Documentation/virtual/kvm/s390-pv-boot.txt >> @@ -0,0 +1,62 @@ >> +Boot/IPL of Protected VMs >> +======================== >> + >> +Summary: >> + >> +Protected VMs are encrypted while not running. On IPL a small >> +plaintext bootloader is started which provides information about the >> +encrypted components and necessary metadata to KVM to decrypt it. >> + >> +Based on this data, KVM will make the PV known to the Ultravisor and >> +instruct it to secure its memory, decrypt the components and verify >> +the data and address list hashes, to ensure integrity. Afterwards KVM >> +can run the PV via SIE which the UV will intercept and execute on >> +KVM's behalf. >> + >> +The switch into PV mode lets us load encrypted guest executables and >> +data via every available method (network, dasd, scsi, direct kernel, >> +...) without the need to change the boot process. >> + >> + >> +Diag308: >> + >> +This diagnose instruction is the basis vor VM IPL. The VM can set and > > s/vor/for/ > >> +retrieve IPL information blocks, that specify the IPL method/devices >> +and request VM memory and subsystem resets, as well as IPLs. >> + >> +For PVs this concept has been continued with new subcodes: >> + >> +Subcode 8: Set an IPL Information Block of type 5. >> +Subcode 9: Store the saved block in guest memory >> +Subcode 10: Move into Protected Virtualization mode >> + >> +The new PV load-device-specific-parameters field specifies all data, >> +that is necessary to move into PV mode. >> + >> +* PV Header origin >> +* PV Header length >> +* List of Components composed of: >> + * AES-XTS Tweak prefix >> + * Origin >> + * Size >> + >> +The PV header contains the keys and hashes, which the UV will use to >> +decrypt and verify the PV, as well as control flags and a start PSW. >> + >> +The components are for instance an encrypted kernel, kernel cmd and >> +initrd. The components are decrypted by the UV. >> + >> +All non-decrypted data of the non-PV guest instance are zero on first >> +access of the PV. >> + >> + >> +When running in a protected mode some subcodes will result in >> +exceptions or return error codes. >> + >> +Subcodes 4 and 7 will result in specification exceptions. >> +When removing a secure VM, the UV will clear all memory, so we can't >> +have non-clearing IPL subcodes. >> + >> +Subcodes 8, 9, 10 will result in specification exceptions. >> +Re-IPL into a protected mode is only possible via a detour into non >> +protected mode. > > So... what do we IPL from? Is there still a need for the bios? > > (Sorry, I'm a bit confused here.) > We load a blob via the bios (all methods are supported) and that blob moves itself into protected mode. I.e. it has a small unprotected stub, the rest is an encrypted kernel.
Attachment:
signature.asc
Description: OpenPGP digital signature
