[RFC,30/37] DOCUMENTATION: protvirt: Diag 308 IPL
diff mbox series

Message ID 20191024114059.102802-31-frankja@linux.ibm.com
State New
Headers show
Series
  • KVM: s390: Add support for protected VMs
Related show

Commit Message

Janosch Frank Oct. 24, 2019, 11:40 a.m. UTC
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

Comments

Cornelia Huck Nov. 6, 2019, 4:48 p.m. UTC | #1
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.)
Janosch Frank Nov. 6, 2019, 5:05 p.m. UTC | #2
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.
Cornelia Huck Nov. 6, 2019, 5:37 p.m. UTC | #3
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?
Janosch Frank Nov. 6, 2019, 9:02 p.m. UTC | #4
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
Cornelia Huck Nov. 7, 2019, 8:53 a.m. UTC | #5
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.
Janosch Frank Nov. 7, 2019, 8:59 a.m. UTC | #6
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.

Patch
diff mbox series

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.