| Message ID | 20191024114059.102802-31-frankja@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: s390: Add support for protected VMs | expand |
On Thu, 24 Oct 2019 07:40:52 -0400 Janosch Frank <frankja@linux.ibm.com> wrote: > Description of changes that are necessary to move a KVM VM into > Protected Virtualization mode. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > --- > 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.)
On 11/6/19 5:48 PM, Cornelia Huck wrote: > On Thu, 24 Oct 2019 07:40:52 -0400 > Janosch Frank <frankja@linux.ibm.com> wrote: > >> Description of changes that are necessary to move a KVM VM into >> Protected Virtualization mode. >> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >> --- >> 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.
On Wed, 6 Nov 2019 18:05:22 +0100 Janosch Frank <frankja@linux.ibm.com> wrote: > On 11/6/19 5:48 PM, Cornelia Huck wrote: > > On Thu, 24 Oct 2019 07:40:52 -0400 > > Janosch Frank <frankja@linux.ibm.com> wrote: > > > >> Description of changes that are necessary to move a KVM VM into > >> Protected Virtualization mode. > >> > >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > >> --- > >> Documentation/virtual/kvm/s390-pv-boot.txt | 62 ++++++++++++++++++++++ > >> 1 file changed, 62 insertions(+) > >> create mode 100644 Documentation/virtual/kvm/s390-pv-boot.txt > > 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. > Ok. The magic is in the loaded kernel, and we don't need modifications to the bios?
On 11/6/19 6:37 PM, Cornelia Huck wrote: > On Wed, 6 Nov 2019 18:05:22 +0100 > Janosch Frank <frankja@linux.ibm.com> wrote: > >> On 11/6/19 5:48 PM, Cornelia Huck wrote: >>> On Thu, 24 Oct 2019 07:40:52 -0400 >>> Janosch Frank <frankja@linux.ibm.com> wrote: >>> >>>> Description of changes that are necessary to move a KVM VM into >>>> Protected Virtualization mode. >>>> >>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >>>> --- >>>> Documentation/virtual/kvm/s390-pv-boot.txt | 62 ++++++++++++++++++++++ >>>> 1 file changed, 62 insertions(+) >>>> create mode 100644 Documentation/virtual/kvm/s390-pv-boot.txt > >>> 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. >> > > Ok. The magic is in the loaded kernel, and we don't need modifications > to the bios? > Yes. The order is: * We load a blob via the bios or direct kernel boot. * That blob consists of a small stub, a header and an encrypted blob glued together * The small stub does the diag 308 subcode 8 and 10. * Subcode 8 basically passes the header that describes the encrypted blob to the Ultravisor (well rather registers it with qemu to pass on later) * Subcode 10 tells QEMU to move the VM into protected mode * A lot of APIs in KVM and the Ultravisor are called * The protected VM starts * A memory mover copies the now unencrypted, but protected kernel to its intended place and jumps into the entry function * Linux boots and detects, that it is protected and needs to use bounce buffers
On Wed, 6 Nov 2019 22:02:41 +0100 Janosch Frank <frankja@linux.ibm.com> wrote: > On 11/6/19 6:37 PM, Cornelia Huck wrote: > > On Wed, 6 Nov 2019 18:05:22 +0100 > > Janosch Frank <frankja@linux.ibm.com> wrote: > > > >> On 11/6/19 5:48 PM, Cornelia Huck wrote: > >>> On Thu, 24 Oct 2019 07:40:52 -0400 > >>> Janosch Frank <frankja@linux.ibm.com> wrote: > >>> > >>>> Description of changes that are necessary to move a KVM VM into > >>>> Protected Virtualization mode. > >>>> > >>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > >>>> --- > >>>> Documentation/virtual/kvm/s390-pv-boot.txt | 62 ++++++++++++++++++++++ > >>>> 1 file changed, 62 insertions(+) > >>>> create mode 100644 Documentation/virtual/kvm/s390-pv-boot.txt > > > >>> 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. > >> > > > > Ok. The magic is in the loaded kernel, and we don't need modifications > > to the bios? > > > > Yes. > > The order is: > * We load a blob via the bios or direct kernel boot. > * That blob consists of a small stub, a header and an encrypted blob > glued together > * The small stub does the diag 308 subcode 8 and 10. > * Subcode 8 basically passes the header that describes the encrypted > blob to the Ultravisor (well rather registers it with qemu to pass on later) > * Subcode 10 tells QEMU to move the VM into protected mode > * A lot of APIs in KVM and the Ultravisor are called > * The protected VM starts > * A memory mover copies the now unencrypted, but protected kernel to its > intended place and jumps into the entry function > * Linux boots and detects, that it is protected and needs to use bounce > buffers > Thanks, this explanation makes things much clearer.
On 11/7/19 9:53 AM, Cornelia Huck wrote: > On Wed, 6 Nov 2019 22:02:41 +0100 > Janosch Frank <frankja@linux.ibm.com> wrote: > >> On 11/6/19 6:37 PM, Cornelia Huck wrote: >>> On Wed, 6 Nov 2019 18:05:22 +0100 >>> Janosch Frank <frankja@linux.ibm.com> wrote: >>> >>>> On 11/6/19 5:48 PM, Cornelia Huck wrote: >>>>> On Thu, 24 Oct 2019 07:40:52 -0400 >>>>> Janosch Frank <frankja@linux.ibm.com> wrote: >>>>> >>>>>> Description of changes that are necessary to move a KVM VM into >>>>>> Protected Virtualization mode. >>>>>> >>>>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >>>>>> --- >>>>>> Documentation/virtual/kvm/s390-pv-boot.txt | 62 ++++++++++++++++++++++ >>>>>> 1 file changed, 62 insertions(+) >>>>>> create mode 100644 Documentation/virtual/kvm/s390-pv-boot.txt >>> >>>>> 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. >>>> >>> >>> Ok. The magic is in the loaded kernel, and we don't need modifications >>> to the bios? >>> >> >> Yes. >> >> The order is: >> * We load a blob via the bios or direct kernel boot. >> * That blob consists of a small stub, a header and an encrypted blob >> glued together >> * The small stub does the diag 308 subcode 8 and 10. >> * Subcode 8 basically passes the header that describes the encrypted >> blob to the Ultravisor (well rather registers it with qemu to pass on later) >> * Subcode 10 tells QEMU to move the VM into protected mode >> * A lot of APIs in KVM and the Ultravisor are called >> * The protected VM starts >> * A memory mover copies the now unencrypted, but protected kernel to its >> intended place and jumps into the entry function >> * Linux boots and detects, that it is protected and needs to use bounce >> buffers >> > > Thanks, this explanation makes things much clearer. NP We seem to assume that all of this is easily understandable, but we are obviously biased :-) I'll try to improve Documentation by adding Pierre to the discussion, as he wasn't involved in the project yet.
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 +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.
Description of changes that are necessary to move a KVM VM into Protected Virtualization mode. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> --- Documentation/virtual/kvm/s390-pv-boot.txt | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/virtual/kvm/s390-pv-boot.txt