| Message ID | 20191024114059.102802-18-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:39 -0400 Janosch Frank <frankja@linux.ibm.com> wrote: > As guest memory is inaccessible and information about the guest's > state is very limited, new ways for instruction emulation have been > introduced. > > With a bounce area for guest GRs and instruction data, guest state > leaks can be limited by the Ultravisor. KVM now has to move > instruction input and output through these areas. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > --- > Documentation/virtual/kvm/s390-pv.txt | 47 +++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > > diff --git a/Documentation/virtual/kvm/s390-pv.txt b/Documentation/virtual/kvm/s390-pv.txt > index e09f2dc5f164..cb08d78a7922 100644 > --- a/Documentation/virtual/kvm/s390-pv.txt > +++ b/Documentation/virtual/kvm/s390-pv.txt > @@ -48,3 +48,50 @@ interception codes have been introduced. One which tells us that CRs > have changed. And one for PSW bit 13 changes. The CRs and the PSW in > the state description only contain the mask bits and no further info > like the current instruction address. > + > + > +Instruction emulation: > +With the format 4 state description the SIE instruction already s/description/description,/ > +interprets more instructions than it does with format 2. As it is not > +able to interpret all instruction, the SIE and the UV safeguard KVM's s/instruction/instructions/ > +emulation inputs and outputs. > + > +Guest GRs and most of the instruction data, like IO data structures Hm, what 'IO data structures'? > +are filtered. Instruction data is copied to and from the Secure > +Instruction Data Area. Guest GRs are put into / retrieved from the > +Interception-Data block. > + > +The Interception-Data block from the state description's offset 0x380 > +contains GRs 0 - 16. Only GR values needed to emulate an instruction > +will be copied into this area. > + > +The Interception Parameters state description field still contains the > +the bytes of the instruction text but with pre-set register > +values. I.e. each instruction always uses the same instruction text, > +to not leak guest instruction text. > + > +The Secure Instruction Data Area contains instruction storage > +data. Data for diag 500 is exempt from that and has to be moved > +through shared buffers to KVM. I find this paragraph a bit confusing. What does that imply for diag 500 interception? Data is still present in gprs 1-4? (Also, why only diag 500? Because it is the 'reserved for kvm' diagnose call?) > + > +When SIE intercepts an instruction, it will only allow data and > +program interrupts for this instruction to be moved to the guest via > +the two data areas discussed before. Other data is ignored or results > +in validity interceptions. > + > + > +Instruction emulation interceptions: > +There are two types of SIE secure instruction intercepts. The normal > +and the notification type. Normal secure instruction intercepts will > +make the guest pending for instruction completion of the intercepted > +instruction type, i.e. on SIE entry it is attempted to complete > +emulation of the instruction with the data provided by KVM. That might > +be a program exception or instruction completion. > + > +The notification type intercepts inform KVM about guest environment > +changes due to guest instruction interpretation. Such an interception 'interpretation by SIE' ? > +is recognized for the store prefix instruction and provides the new > +lowcore location for mapping change notification arming. Any KVM data > +in the data areas is ignored, program exceptions are not injected and > +execution continues on next SIE entry, as if no intercept had > +happened.
On Thu, 14 Nov 2019 16:15:26 +0100 Cornelia Huck <cohuck@redhat.com> wrote: > On Thu, 24 Oct 2019 07:40:39 -0400 > Janosch Frank <frankja@linux.ibm.com> wrote: > > > As guest memory is inaccessible and information about the guest's > > state is very limited, new ways for instruction emulation have been > > introduced. > > > > With a bounce area for guest GRs and instruction data, guest state > > leaks can be limited by the Ultravisor. KVM now has to move > > instruction input and output through these areas. > > > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > > --- > > Documentation/virtual/kvm/s390-pv.txt | 47 > > +++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) > > > > diff --git a/Documentation/virtual/kvm/s390-pv.txt > > b/Documentation/virtual/kvm/s390-pv.txt index > > e09f2dc5f164..cb08d78a7922 100644 --- > > a/Documentation/virtual/kvm/s390-pv.txt +++ > > b/Documentation/virtual/kvm/s390-pv.txt @@ -48,3 +48,50 @@ > > interception codes have been introduced. One which tells us that > > CRs have changed. And one for PSW bit 13 changes. The CRs and the > > PSW in the state description only contain the mask bits and no > > further info like the current instruction address. + > > + > > +Instruction emulation: > > +With the format 4 state description the SIE instruction already > > s/description/description,/ > > > +interprets more instructions than it does with format 2. As it is > > not +able to interpret all instruction, the SIE and the UV > > safeguard KVM's > > s/instruction/instructions/ > > > +emulation inputs and outputs. > > + > > +Guest GRs and most of the instruction data, like IO data > > structures > > Hm, what 'IO data structures'? the various IRB and ORB of I/O instructions > > +are filtered. Instruction data is copied to and from the Secure > > +Instruction Data Area. Guest GRs are put into / retrieved from the > > +Interception-Data block. > > + > > +The Interception-Data block from the state description's offset > > 0x380 +contains GRs 0 - 16. Only GR values needed to emulate an > > instruction +will be copied into this area. > > + > > +The Interception Parameters state description field still contains > > the +the bytes of the instruction text but with pre-set register > > +values. I.e. each instruction always uses the same instruction > > text, +to not leak guest instruction text. > > + > > +The Secure Instruction Data Area contains instruction storage > > +data. Data for diag 500 is exempt from that and has to be moved > > +through shared buffers to KVM. > > I find this paragraph a bit confusing. What does that imply for diag > 500 interception? Data is still present in gprs 1-4? no registers are leaked in the registers. registers are always only exposed through the state description. > (Also, why only diag 500? Because it is the 'reserved for kvm' > diagnose call?) > > > + > > +When SIE intercepts an instruction, it will only allow data and > > +program interrupts for this instruction to be moved to the guest > > via +the two data areas discussed before. Other data is ignored or > > results +in validity interceptions. > > + > > + > > +Instruction emulation interceptions: > > +There are two types of SIE secure instruction intercepts. The > > normal +and the notification type. Normal secure instruction > > intercepts will +make the guest pending for instruction completion > > of the intercepted +instruction type, i.e. on SIE entry it is > > attempted to complete +emulation of the instruction with the data > > provided by KVM. That might +be a program exception or instruction > > completion. + > > +The notification type intercepts inform KVM about guest environment > > +changes due to guest instruction interpretation. Such an > > interception > > 'interpretation by SIE' ? > > > +is recognized for the store prefix instruction and provides the new > > +lowcore location for mapping change notification arming. Any KVM > > data +in the data areas is ignored, program exceptions are not > > injected and +execution continues on next SIE entry, as if no > > intercept had +happened. >
On Thu, 14 Nov 2019 16:20:24 +0100 Claudio Imbrenda <imbrenda@linux.ibm.com> wrote: > On Thu, 14 Nov 2019 16:15:26 +0100 > Cornelia Huck <cohuck@redhat.com> wrote: > > > On Thu, 24 Oct 2019 07:40:39 -0400 > > Janosch Frank <frankja@linux.ibm.com> wrote: > > > > > As guest memory is inaccessible and information about the guest's > > > state is very limited, new ways for instruction emulation have been > > > introduced. > > > > > > With a bounce area for guest GRs and instruction data, guest state > > > leaks can be limited by the Ultravisor. KVM now has to move > > > instruction input and output through these areas. > > > > > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > > > --- > > > Documentation/virtual/kvm/s390-pv.txt | 47 > > > +++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) > > > > > > diff --git a/Documentation/virtual/kvm/s390-pv.txt > > > b/Documentation/virtual/kvm/s390-pv.txt index > > > e09f2dc5f164..cb08d78a7922 100644 --- > > > a/Documentation/virtual/kvm/s390-pv.txt +++ > > > b/Documentation/virtual/kvm/s390-pv.txt @@ -48,3 +48,50 @@ > > > interception codes have been introduced. One which tells us that > > > CRs have changed. And one for PSW bit 13 changes. The CRs and the > > > PSW in the state description only contain the mask bits and no > > > further info like the current instruction address. + > > > + > > > +Instruction emulation: > > > +With the format 4 state description the SIE instruction already > > > > s/description/description,/ > > > > > +interprets more instructions than it does with format 2. As it is > > > not +able to interpret all instruction, the SIE and the UV > > > safeguard KVM's > > > > s/instruction/instructions/ > > > > > +emulation inputs and outputs. > > > + > > > +Guest GRs and most of the instruction data, like IO data > > > structures > > > > Hm, what 'IO data structures'? > > the various IRB and ORB of I/O instructions Would be good to mention them as examples :) > > > > +are filtered. Instruction data is copied to and from the Secure > > > +Instruction Data Area. Guest GRs are put into / retrieved from the > > > +Interception-Data block. > > > + > > > +The Interception-Data block from the state description's offset > > > 0x380 +contains GRs 0 - 16. Only GR values needed to emulate an > > > instruction +will be copied into this area. > > > + > > > +The Interception Parameters state description field still contains > > > the +the bytes of the instruction text but with pre-set register > > > +values. I.e. each instruction always uses the same instruction > > > text, +to not leak guest instruction text. > > > + > > > +The Secure Instruction Data Area contains instruction storage > > > +data. Data for diag 500 is exempt from that and has to be moved > > > +through shared buffers to KVM. > > > > I find this paragraph a bit confusing. What does that imply for diag > > 500 interception? Data is still present in gprs 1-4? > > no registers are leaked in the registers. registers are always only > exposed through the state description. So, what is so special about diag 500, then? > > > (Also, why only diag 500? Because it is the 'reserved for kvm' > > diagnose call?) > > > > > + > > > +When SIE intercepts an instruction, it will only allow data and > > > +program interrupts for this instruction to be moved to the guest > > > via +the two data areas discussed before. Other data is ignored or > > > results +in validity interceptions. > > > + > > > + > > > +Instruction emulation interceptions: > > > +There are two types of SIE secure instruction intercepts. The > > > normal +and the notification type. Normal secure instruction > > > intercepts will +make the guest pending for instruction completion > > > of the intercepted +instruction type, i.e. on SIE entry it is > > > attempted to complete +emulation of the instruction with the data > > > provided by KVM. That might +be a program exception or instruction > > > completion. + > > > +The notification type intercepts inform KVM about guest environment > > > +changes due to guest instruction interpretation. Such an > > > interception > > > > 'interpretation by SIE' ? > > > > > +is recognized for the store prefix instruction and provides the new > > > +lowcore location for mapping change notification arming. Any KVM > > > data +in the data areas is ignored, program exceptions are not > > > injected and +execution continues on next SIE entry, as if no > > > intercept had +happened. > > >
On 11/14/19 4:41 PM, Cornelia Huck wrote: > On Thu, 14 Nov 2019 16:20:24 +0100 > Claudio Imbrenda <imbrenda@linux.ibm.com> wrote: > >> On Thu, 14 Nov 2019 16:15:26 +0100 >> Cornelia Huck <cohuck@redhat.com> wrote: >> >>> On Thu, 24 Oct 2019 07:40:39 -0400 >>> Janosch Frank <frankja@linux.ibm.com> wrote: >>> >>>> As guest memory is inaccessible and information about the guest's >>>> state is very limited, new ways for instruction emulation have been >>>> introduced. >>>> >>>> With a bounce area for guest GRs and instruction data, guest state >>>> leaks can be limited by the Ultravisor. KVM now has to move >>>> instruction input and output through these areas. >>>> >>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >>>> --- >>>> Documentation/virtual/kvm/s390-pv.txt | 47 >>>> +++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) >>>> >>>> diff --git a/Documentation/virtual/kvm/s390-pv.txt >>>> b/Documentation/virtual/kvm/s390-pv.txt index >>>> e09f2dc5f164..cb08d78a7922 100644 --- >>>> a/Documentation/virtual/kvm/s390-pv.txt +++ >>>> b/Documentation/virtual/kvm/s390-pv.txt @@ -48,3 +48,50 @@ >>>> interception codes have been introduced. One which tells us that >>>> CRs have changed. And one for PSW bit 13 changes. The CRs and the >>>> PSW in the state description only contain the mask bits and no >>>> further info like the current instruction address. + >>>> + >>>> +Instruction emulation: >>>> +With the format 4 state description the SIE instruction already >>> >>> s/description/description,/ >>> >>>> +interprets more instructions than it does with format 2. As it is >>>> not +able to interpret all instruction, the SIE and the UV >>>> safeguard KVM's >>> >>> s/instruction/instructions/ >>> >>>> +emulation inputs and outputs. >>>> + >>>> +Guest GRs and most of the instruction data, like IO data >>>> structures >>> >>> Hm, what 'IO data structures'? >> >> the various IRB and ORB of I/O instructions > > Would be good to mention them as examples :) > >> >>>> +are filtered. Instruction data is copied to and from the Secure >>>> +Instruction Data Area. Guest GRs are put into / retrieved from the >>>> +Interception-Data block. >>>> + >>>> +The Interception-Data block from the state description's offset >>>> 0x380 +contains GRs 0 - 16. Only GR values needed to emulate an >>>> instruction +will be copied into this area. >>>> + >>>> +The Interception Parameters state description field still contains >>>> the +the bytes of the instruction text but with pre-set register >>>> +values. I.e. each instruction always uses the same instruction >>>> text, +to not leak guest instruction text. >>>> + >>>> +The Secure Instruction Data Area contains instruction storage >>>> +data. Data for diag 500 is exempt from that and has to be moved >>>> +through shared buffers to KVM. >>> >>> I find this paragraph a bit confusing. What does that imply for diag >>> 500 interception? Data is still present in gprs 1-4? >> >> no registers are leaked in the registers. registers are always only >> exposed through the state description. > > So, what is so special about diag 500, then? That's mostly a confusion on my side. The SIDAD is 4k max, so we can only move IO "management" data over it like ORBs and stuff. My intention was to point out, that the data which is to be transferred (disk contents, etc.) can't go over the SIDAD but needs to be in a shared page. diag500 was mostly a notification mechanism without a lot of data, right? > >> >>> (Also, why only diag 500? Because it is the 'reserved for kvm' >>> diagnose call?) >>> >>>> + >>>> +When SIE intercepts an instruction, it will only allow data and >>>> +program interrupts for this instruction to be moved to the guest >>>> via +the two data areas discussed before. Other data is ignored or >>>> results +in validity interceptions. >>>> + >>>> + >>>> +Instruction emulation interceptions: >>>> +There are two types of SIE secure instruction intercepts. The >>>> normal +and the notification type. Normal secure instruction >>>> intercepts will +make the guest pending for instruction completion >>>> of the intercepted +instruction type, i.e. on SIE entry it is >>>> attempted to complete +emulation of the instruction with the data >>>> provided by KVM. That might +be a program exception or instruction >>>> completion. + >>>> +The notification type intercepts inform KVM about guest environment >>>> +changes due to guest instruction interpretation. Such an >>>> interception >>> >>> 'interpretation by SIE' ? >>> >>>> +is recognized for the store prefix instruction and provides the new >>>> +lowcore location for mapping change notification arming. Any KVM >>>> data +in the data areas is ignored, program exceptions are not >>>> injected and +execution continues on next SIE entry, as if no >>>> intercept had +happened. >>> >> >
On Thu, 14 Nov 2019 16:55:46 +0100 Janosch Frank <frankja@linux.ibm.com> wrote: > On 11/14/19 4:41 PM, Cornelia Huck wrote: > > On Thu, 14 Nov 2019 16:20:24 +0100 > > Claudio Imbrenda <imbrenda@linux.ibm.com> wrote: > > > >> On Thu, 14 Nov 2019 16:15:26 +0100 > >> Cornelia Huck <cohuck@redhat.com> wrote: > >> > >>> On Thu, 24 Oct 2019 07:40:39 -0400 > >>> Janosch Frank <frankja@linux.ibm.com> wrote: > >>>> +The Secure Instruction Data Area contains instruction storage > >>>> +data. Data for diag 500 is exempt from that and has to be moved > >>>> +through shared buffers to KVM. > >>> > >>> I find this paragraph a bit confusing. What does that imply for diag > >>> 500 interception? Data is still present in gprs 1-4? > >> > >> no registers are leaked in the registers. registers are always only > >> exposed through the state description. > > > > So, what is so special about diag 500, then? > > That's mostly a confusion on my side. > The SIDAD is 4k max, so we can only move IO "management" data over it > like ORBs and stuff. My intention was to point out, that the data which > is to be transferred (disk contents, etc.) can't go over the SIDAD but > needs to be in a shared page. > > diag500 was mostly a notification mechanism without a lot of data, right? Yes; the main information in there are the schid identifying the subchannel, the virtqueue number, and a cookie value, all of which fit into the registers. So this goes via the sidad as well?
On 11/14/19 5:03 PM, Cornelia Huck wrote: > On Thu, 14 Nov 2019 16:55:46 +0100 > Janosch Frank <frankja@linux.ibm.com> wrote: > >> On 11/14/19 4:41 PM, Cornelia Huck wrote: >>> On Thu, 14 Nov 2019 16:20:24 +0100 >>> Claudio Imbrenda <imbrenda@linux.ibm.com> wrote: >>> >>>> On Thu, 14 Nov 2019 16:15:26 +0100 >>>> Cornelia Huck <cohuck@redhat.com> wrote: >>>> >>>>> On Thu, 24 Oct 2019 07:40:39 -0400 >>>>> Janosch Frank <frankja@linux.ibm.com> wrote: > >>>>>> +The Secure Instruction Data Area contains instruction storage >>>>>> +data. Data for diag 500 is exempt from that and has to be moved >>>>>> +through shared buffers to KVM. >>>>> >>>>> I find this paragraph a bit confusing. What does that imply for diag >>>>> 500 interception? Data is still present in gprs 1-4? >>>> >>>> no registers are leaked in the registers. registers are always only >>>> exposed through the state description. >>> >>> So, what is so special about diag 500, then? >> >> That's mostly a confusion on my side. >> The SIDAD is 4k max, so we can only move IO "management" data over it >> like ORBs and stuff. My intention was to point out, that the data which >> is to be transferred (disk contents, etc.) can't go over the SIDAD but >> needs to be in a shared page. >> >> diag500 was mostly a notification mechanism without a lot of data, right? > > Yes; the main information in there are the schid identifying the > subchannel, the virtqueue number, and a cookie value, all of which fit > into the registers. > > So this goes via the sidad as well? > Only referenced data goes over the SIDA, register values go into offset 0x380 of the SIE state description. If an instruction has an address in a register, we will receive a bogus address and the referenced data in the SIDA. SCLP has a code and an address as register values. We will get the code and a bogus address in the register area. The SCCB will be in the SIDA.
diff --git a/Documentation/virtual/kvm/s390-pv.txt b/Documentation/virtual/kvm/s390-pv.txt index e09f2dc5f164..cb08d78a7922 100644 --- a/Documentation/virtual/kvm/s390-pv.txt +++ b/Documentation/virtual/kvm/s390-pv.txt @@ -48,3 +48,50 @@ interception codes have been introduced. One which tells us that CRs have changed. And one for PSW bit 13 changes. The CRs and the PSW in the state description only contain the mask bits and no further info like the current instruction address. + + +Instruction emulation: +With the format 4 state description the SIE instruction already +interprets more instructions than it does with format 2. As it is not +able to interpret all instruction, the SIE and the UV safeguard KVM's +emulation inputs and outputs. + +Guest GRs and most of the instruction data, like IO data structures +are filtered. Instruction data is copied to and from the Secure +Instruction Data Area. Guest GRs are put into / retrieved from the +Interception-Data block. + +The Interception-Data block from the state description's offset 0x380 +contains GRs 0 - 16. Only GR values needed to emulate an instruction +will be copied into this area. + +The Interception Parameters state description field still contains the +the bytes of the instruction text but with pre-set register +values. I.e. each instruction always uses the same instruction text, +to not leak guest instruction text. + +The Secure Instruction Data Area contains instruction storage +data. Data for diag 500 is exempt from that and has to be moved +through shared buffers to KVM. + +When SIE intercepts an instruction, it will only allow data and +program interrupts for this instruction to be moved to the guest via +the two data areas discussed before. Other data is ignored or results +in validity interceptions. + + +Instruction emulation interceptions: +There are two types of SIE secure instruction intercepts. The normal +and the notification type. Normal secure instruction intercepts will +make the guest pending for instruction completion of the intercepted +instruction type, i.e. on SIE entry it is attempted to complete +emulation of the instruction with the data provided by KVM. That might +be a program exception or instruction completion. + +The notification type intercepts inform KVM about guest environment +changes due to guest instruction interpretation. Such an interception +is recognized for the store prefix instruction and provides the new +lowcore location for mapping change notification arming. Any KVM data +in the data areas is ignored, program exceptions are not injected and +execution continues on next SIE entry, as if no intercept had +happened.
As guest memory is inaccessible and information about the guest's state is very limited, new ways for instruction emulation have been introduced. With a bounce area for guest GRs and instruction data, guest state leaks can be limited by the Ultravisor. KVM now has to move instruction input and output through these areas. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> --- Documentation/virtual/kvm/s390-pv.txt | 47 +++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)