| Message ID | 20170615215051.3256-1-jarkko.sakkinen@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Jarkko, See my reply below. On 6/16/2017 9:50 AM, Jarkko Sakkinen wrote: > Updated documentation to document the constraint, which prevents > emulating the MSR values for VM guests. > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > --- > v2: fix typos > Documentation/x86/intel_sgx.rst | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/Documentation/x86/intel_sgx.rst b/Documentation/x86/intel_sgx.rst > index ee1db2ca2e39..71026732af61 100644 > --- a/Documentation/x86/intel_sgx.rst > +++ b/Documentation/x86/intel_sgx.rst > @@ -77,6 +77,22 @@ every time when an enclave is launched. This does not scale because for > generic case because BIOS might lock down the MSRs before handover to > the OS. > > +Virtualization > +-------------- > + > +The values for IA32_SGXLEPUBKEYHASHn MSRs cannot be emulated for a virtual > +machine guest. The MSRs can certainly be emulated. KVM is already emulating lots of MSRs and I don't see why KVM cannot emulate this one. Maybe you have a different definition of "emulate" here, which I cannot understand (sorry). If this one cannot be emulated, essentially you are saying KVM SGX virtualization cannot be implemented, in which case I don't know what I am working on. It would easily seem feasible to hold virtual values for these > +MSRs, trap EINIT and use the host LE to generate a token when a guest LE is > +initialized. Can you explain why host LE should generate a token when guest LE is initialized? I've explained many times host LE will never generate token for guest in any circumstances, but looks still you are thinking host LE can generate token for guest, so I am trying to understand why you think in this way. Maybe I can explain again in this way: "host LE generates token for guest" is some kind identical to "one LE running in remote machine generates token for my physical machine". Do you think it is reasonable? Again, guest SGX software will run it's own LE, and guest's LE will generate token for other enclaves. In fact, KVM really doesn't care guest's LE's behavior -- whether it generates token for other or not, KVM only wants to guarantee guest's EINIT will run in assumed behavior -- either succeed or fail -- according to EINIT's hardware behavior defined in SDM. > + > +However, looking at the pseudo code of ENCLS(EINIT) from the SDM there is > +a constraint that the instruction will fail if ATTRIBUTES.EINITTOKENKEY is > +set (the documentation does not tell the reason why the constraint exists > +but it exists). This is the reason why KVM needs to update guest's *virtual* IA32_SGXLEPUBKEYHASHn to physical MSRs, to guarantee EINIT for guest's LE will succeed. Thanks, -Kai > + > +Thus, only when the MSRs are left unlocked before handover to the OS the > +setting of these MSRs can be supported for VM guests. > + > Debug enclaves > -------------- > >
On 6/16/2017 11:52 AM, Huang, Kai wrote: > Hi Jarkko, > > See my reply below. > > On 6/16/2017 9:50 AM, Jarkko Sakkinen wrote: >> Updated documentation to document the constraint, which prevents >> emulating the MSR values for VM guests. >> >> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> --- >> v2: fix typos >> Documentation/x86/intel_sgx.rst | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/Documentation/x86/intel_sgx.rst >> b/Documentation/x86/intel_sgx.rst >> index ee1db2ca2e39..71026732af61 100644 >> --- a/Documentation/x86/intel_sgx.rst >> +++ b/Documentation/x86/intel_sgx.rst >> @@ -77,6 +77,22 @@ every time when an enclave is launched. This does >> not scale because for >> generic case because BIOS might lock down the MSRs before handover to >> the OS. >> +Virtualization >> +-------------- >> + >> +The values for IA32_SGXLEPUBKEYHASHn MSRs cannot be emulated for a >> virtual >> +machine guest. > > The MSRs can certainly be emulated. KVM is already emulating lots of > MSRs and I don't see why KVM cannot emulate this one. Maybe you have a > different definition of "emulate" here, which I cannot understand > (sorry). If this one cannot be emulated, essentially you are saying KVM > SGX virtualization cannot be implemented, in which case I don't know > what I am working on. > > It would easily seem feasible to hold virtual values for these >> +MSRs, trap EINIT and use the host LE to generate a token when a guest >> LE is >> +initialized. > > Can you explain why host LE should generate a token when guest LE is > initialized? > > I've explained many times host LE will never generate token for guest in > any circumstances, but looks still you are thinking host LE can generate > token for guest, so I am trying to understand why you think in this way. > > Maybe I can explain again in this way: "host LE generates token for > guest" is some kind identical to "one LE running in remote machine > generates token for my physical machine". Do you think it is reasonable? > > Again, guest SGX software will run it's own LE, and guest's LE will > generate token for other enclaves. In fact, KVM really doesn't care > guest's LE's behavior -- whether it generates token for other or not, > KVM only wants to guarantee guest's EINIT will run in assumed behavior > -- either succeed or fail -- according to EINIT's hardware behavior > defined in SDM. > >> + >> +However, looking at the pseudo code of ENCLS(EINIT) from the SDM >> there is >> +a constraint that the instruction will fail if >> ATTRIBUTES.EINITTOKENKEY is >> +set (the documentation does not tell the reason why the constraint >> exists >> +but it exists). > > This is the reason why KVM needs to update guest's *virtual* > IA32_SGXLEPUBKEYHASHn to physical MSRs, to guarantee EINIT for guest's > LE will succeed. > > Thanks, > -Kai > >> + >> +Thus, only when the MSRs are left unlocked before handover to the OS the >> +setting of these MSRs can be supported for VM guests. Sorry Jarkko I missed this part. Yes you are absolutely right. If physical MSRs are locked, guest can only run LE which matches the physical MSRs. Physical MSRs values will be present to guest and those MSRs will be presented as *locked* to guest as well. KVM will simply fail to create the guest if any virtual IA32_SGXLEPUBKEYHASHn value is specified when creating the guest. Thanks, -Kai >> + >> Debug enclaves >> -------------- >> > _______________________________________________ > intel-sgx-kernel-dev mailing list > intel-sgx-kernel-dev@lists.01.org > https://lists.01.org/mailman/listinfo/intel-sgx-kernel-dev >
On Fri, Jun 16, 2017 at 11:52:43AM +1200, Huang, Kai wrote: > Hi Jarkko, > > See my reply below. > > On 6/16/2017 9:50 AM, Jarkko Sakkinen wrote: > > Updated documentation to document the constraint, which prevents > > emulating the MSR values for VM guests. > > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > --- > > v2: fix typos > > Documentation/x86/intel_sgx.rst | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/Documentation/x86/intel_sgx.rst b/Documentation/x86/intel_sgx.rst > > index ee1db2ca2e39..71026732af61 100644 > > --- a/Documentation/x86/intel_sgx.rst > > +++ b/Documentation/x86/intel_sgx.rst > > @@ -77,6 +77,22 @@ every time when an enclave is launched. This does not scale because for > > generic case because BIOS might lock down the MSRs before handover to > > the OS. > > +Virtualization > > +-------------- > > + > > +The values for IA32_SGXLEPUBKEYHASHn MSRs cannot be emulated for a virtual > > +machine guest. > > The MSRs can certainly be emulated. KVM is already emulating lots of MSRs > and I don't see why KVM cannot emulate this one. Maybe you have a different > definition of "emulate" here, which I cannot understand (sorry). If this one > cannot be emulated, essentially you are saying KVM SGX virtualization cannot > be implemented, in which case I don't know what I am working on. > > It would easily seem feasible to hold virtual values for these > > +MSRs, trap EINIT and use the host LE to generate a token when a guest LE is > > +initialized. > > Can you explain why host LE should generate a token when guest LE is > initialized? > > I've explained many times host LE will never generate token for guest in any > circumstances, but looks still you are thinking host LE can generate token > for guest, so I am trying to understand why you think in this way. > > Maybe I can explain again in this way: "host LE generates token for guest" > is some kind identical to "one LE running in remote machine generates token > for my physical machine". Do you think it is reasonable? > > Again, guest SGX software will run it's own LE, and guest's LE will generate > token for other enclaves. In fact, KVM really doesn't care guest's LE's > behavior -- whether it generates token for other or not, KVM only wants to > guarantee guest's EINIT will run in assumed behavior -- either succeed or > fail -- according to EINIT's hardware behavior defined in SDM. > > > + > > +However, looking at the pseudo code of ENCLS(EINIT) from the SDM there is > > +a constraint that the instruction will fail if ATTRIBUTES.EINITTOKENKEY is > > +set (the documentation does not tell the reason why the constraint exists > > +but it exists). > > This is the reason why KVM needs to update guest's *virtual* > IA32_SGXLEPUBKEYHASHn to physical MSRs, to guarantee EINIT for guest's LE > will succeed. > > Thanks, > -Kai > > > + > > +Thus, only when the MSRs are left unlocked before handover to the OS the > > +setting of these MSRs can be supported for VM guests. > > + > > Debug enclaves > > -------------- > > In the other thread you explained all sorts of stuff but *did not* say why it is non-doable. One sentence would have been enough. If there was no such check ENCLS(EINIT), it would be a feasible approach to never change the MSRs. Do you think it is better not to document this corner case?? /Jarkko
On Fri, Jun 16, 2017 at 02:43:32PM +1200, Huang, Kai wrote: > > > On 6/16/2017 11:52 AM, Huang, Kai wrote: > > Hi Jarkko, > > > > See my reply below. > > > > On 6/16/2017 9:50 AM, Jarkko Sakkinen wrote: > > > Updated documentation to document the constraint, which prevents > > > emulating the MSR values for VM guests. > > > > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > --- > > > v2: fix typos > > > Documentation/x86/intel_sgx.rst | 16 ++++++++++++++++ > > > 1 file changed, 16 insertions(+) > > > > > > diff --git a/Documentation/x86/intel_sgx.rst > > > b/Documentation/x86/intel_sgx.rst > > > index ee1db2ca2e39..71026732af61 100644 > > > --- a/Documentation/x86/intel_sgx.rst > > > +++ b/Documentation/x86/intel_sgx.rst > > > @@ -77,6 +77,22 @@ every time when an enclave is launched. This does > > > not scale because for > > > generic case because BIOS might lock down the MSRs before handover to > > > the OS. > > > +Virtualization > > > +-------------- > > > + > > > +The values for IA32_SGXLEPUBKEYHASHn MSRs cannot be emulated for a > > > virtual > > > +machine guest. > > > > The MSRs can certainly be emulated. KVM is already emulating lots of > > MSRs and I don't see why KVM cannot emulate this one. Maybe you have a > > different definition of "emulate" here, which I cannot understand > > (sorry). If this one cannot be emulated, essentially you are saying KVM > > SGX virtualization cannot be implemented, in which case I don't know > > what I am working on. > > > > It would easily seem feasible to hold virtual values for these > > > +MSRs, trap EINIT and use the host LE to generate a token when a > > > guest LE is > > > +initialized. > > > > Can you explain why host LE should generate a token when guest LE is > > initialized? > > > > I've explained many times host LE will never generate token for guest in > > any circumstances, but looks still you are thinking host LE can generate > > token for guest, so I am trying to understand why you think in this way. > > > > Maybe I can explain again in this way: "host LE generates token for > > guest" is some kind identical to "one LE running in remote machine > > generates token for my physical machine". Do you think it is reasonable? > > > > Again, guest SGX software will run it's own LE, and guest's LE will > > generate token for other enclaves. In fact, KVM really doesn't care > > guest's LE's behavior -- whether it generates token for other or not, > > KVM only wants to guarantee guest's EINIT will run in assumed behavior > > -- either succeed or fail -- according to EINIT's hardware behavior > > defined in SDM. > > > > > + > > > +However, looking at the pseudo code of ENCLS(EINIT) from the SDM > > > there is > > > +a constraint that the instruction will fail if > > > ATTRIBUTES.EINITTOKENKEY is > > > +set (the documentation does not tell the reason why the constraint > > > exists > > > +but it exists). > > > > This is the reason why KVM needs to update guest's *virtual* > > IA32_SGXLEPUBKEYHASHn to physical MSRs, to guarantee EINIT for guest's > > LE will succeed. > > > > Thanks, > > -Kai > > > > > + > > > +Thus, only when the MSRs are left unlocked before handover to the OS the > > > +setting of these MSRs can be supported for VM guests. > > Sorry Jarkko I missed this part. Yes you are absolutely right. If physical > MSRs are locked, guest can only run LE which matches the physical MSRs. > Physical MSRs values will be present to guest and those MSRs will be > presented as *locked* to guest as well. KVM will simply fail to create the > guest if any virtual IA32_SGXLEPUBKEYHASHn value is specified when creating > the guest. > > Thanks, > -Kai The locked MSRs part is inherently obvious and is already in my documentation if you care to read it properly. /Jarkko
On Fri, Jun 16, 2017 at 09:07:35AM +0200, Jarkko Sakkinen wrote: > > Sorry Jarkko I missed this part. Yes you are absolutely right. If physical > > MSRs are locked, guest can only run LE which matches the physical MSRs. > > Physical MSRs values will be present to guest and those MSRs will be > > presented as *locked* to guest as well. KVM will simply fail to create the > > guest if any virtual IA32_SGXLEPUBKEYHASHn value is specified when creating > > the guest. > > > > Thanks, > > -Kai > > The locked MSRs part is inherently obvious and is already in my > documentation if you care to read it properly. +Thus, only when the MSRs are left unlocked before handover to the OS the +setting of these MSRs can be supported for VM guests. /Jarkko
On Fri, Jun 16, 2017 at 09:10:58AM +0200, Jarkko Sakkinen wrote: > On Fri, Jun 16, 2017 at 09:07:35AM +0200, Jarkko Sakkinen wrote: > > > Sorry Jarkko I missed this part. Yes you are absolutely right. If physical > > > MSRs are locked, guest can only run LE which matches the physical MSRs. > > > Physical MSRs values will be present to guest and those MSRs will be > > > presented as *locked* to guest as well. KVM will simply fail to create the > > > guest if any virtual IA32_SGXLEPUBKEYHASHn value is specified when creating > > > the guest. > > > > > > Thanks, > > > -Kai > > > > The locked MSRs part is inherently obvious and is already in my > > documentation if you care to read it properly. > > +Thus, only when the MSRs are left unlocked before handover to the OS the > +setting of these MSRs can be supported for VM guests. > > /Jarkko I've now applied this and will squash it. If there is something wrong in my documentation I'm glad to apply patches to it. /Jarkko
On 6/16/2017 8:15 PM, Jarkko Sakkinen wrote: > On Fri, Jun 16, 2017 at 09:10:58AM +0200, Jarkko Sakkinen wrote: >> On Fri, Jun 16, 2017 at 09:07:35AM +0200, Jarkko Sakkinen wrote: >>>> Sorry Jarkko I missed this part. Yes you are absolutely right. If physical >>>> MSRs are locked, guest can only run LE which matches the physical MSRs. >>>> Physical MSRs values will be present to guest and those MSRs will be >>>> presented as *locked* to guest as well. KVM will simply fail to create the >>>> guest if any virtual IA32_SGXLEPUBKEYHASHn value is specified when creating >>>> the guest. >>>> >>>> Thanks, >>>> -Kai >>> >>> The locked MSRs part is inherently obvious and is already in my >>> documentation if you care to read it properly. >> >> +Thus, only when the MSRs are left unlocked before handover to the OS the >> +setting of these MSRs can be supported for VM guests. >> >> /Jarkko > > I've now applied this and will squash it. If there is something wrong in > my documentation I'm glad to apply patches to it. Sure. No problem at all. Enjoy your holiday. Thanks, -Kai > > /Jarkko >
On Fri, Jun 16, 2017 at 09:36:31PM +1200, Huang, Kai wrote: > > > On 6/16/2017 8:15 PM, Jarkko Sakkinen wrote: > > On Fri, Jun 16, 2017 at 09:10:58AM +0200, Jarkko Sakkinen wrote: > > > On Fri, Jun 16, 2017 at 09:07:35AM +0200, Jarkko Sakkinen wrote: > > > > > Sorry Jarkko I missed this part. Yes you are absolutely right. If physical > > > > > MSRs are locked, guest can only run LE which matches the physical MSRs. > > > > > Physical MSRs values will be present to guest and those MSRs will be > > > > > presented as *locked* to guest as well. KVM will simply fail to create the > > > > > guest if any virtual IA32_SGXLEPUBKEYHASHn value is specified when creating > > > > > the guest. > > > > > > > > > > Thanks, > > > > > -Kai > > > > > > > > The locked MSRs part is inherently obvious and is already in my > > > > documentation if you care to read it properly. > > > > > > +Thus, only when the MSRs are left unlocked before handover to the OS the > > > +setting of these MSRs can be supported for VM guests. > > > > > > /Jarkko > > > > I've now applied this and will squash it. If there is something wrong in > > my documentation I'm glad to apply patches to it. > > Sure. No problem at all. Enjoy your holiday. > > Thanks, > -Kai Thank you and no worries from my side either :-) Now you have better tools to argument for your strategy now that we have the constraint itself cleanly documented. /Jarkko
On Fri, Jun 16, 2017 at 03:12:26PM +0200, Jarkko Sakkinen wrote: > On Fri, Jun 16, 2017 at 09:36:31PM +1200, Huang, Kai wrote: > > > > > > On 6/16/2017 8:15 PM, Jarkko Sakkinen wrote: > > > On Fri, Jun 16, 2017 at 09:10:58AM +0200, Jarkko Sakkinen wrote: > > > > On Fri, Jun 16, 2017 at 09:07:35AM +0200, Jarkko Sakkinen wrote: > > > > > > Sorry Jarkko I missed this part. Yes you are absolutely right. If physical > > > > > > MSRs are locked, guest can only run LE which matches the physical MSRs. > > > > > > Physical MSRs values will be present to guest and those MSRs will be > > > > > > presented as *locked* to guest as well. KVM will simply fail to create the > > > > > > guest if any virtual IA32_SGXLEPUBKEYHASHn value is specified when creating > > > > > > the guest. > > > > > > > > > > > > Thanks, > > > > > > -Kai > > > > > > > > > > The locked MSRs part is inherently obvious and is already in my > > > > > documentation if you care to read it properly. > > > > > > > > +Thus, only when the MSRs are left unlocked before handover to the OS the > > > > +setting of these MSRs can be supported for VM guests. > > > > > > > > /Jarkko > > > > > > I've now applied this and will squash it. If there is something wrong in > > > my documentation I'm glad to apply patches to it. > > > > Sure. No problem at all. Enjoy your holiday. > > > > Thanks, > > -Kai > > Thank you and no worries from my side either :-) > > Now you have better tools to argument for your strategy now that we > have the constraint itself cleanly documented. > > /Jarkko I.e. this argument was somewhat painful but we got it sorted out and it is better to go it through in this small mailing list than lkml ;-) /Jarkko
diff --git a/Documentation/x86/intel_sgx.rst b/Documentation/x86/intel_sgx.rst index ee1db2ca2e39..71026732af61 100644 --- a/Documentation/x86/intel_sgx.rst +++ b/Documentation/x86/intel_sgx.rst @@ -77,6 +77,22 @@ every time when an enclave is launched. This does not scale because for generic case because BIOS might lock down the MSRs before handover to the OS. +Virtualization +-------------- + +The values for IA32_SGXLEPUBKEYHASHn MSRs cannot be emulated for a virtual +machine guest. It would easily seem feasible to hold virtual values for these +MSRs, trap EINIT and use the host LE to generate a token when a guest LE is +initialized. + +However, looking at the pseudo code of ENCLS(EINIT) from the SDM there is +a constraint that the instruction will fail if ATTRIBUTES.EINITTOKENKEY is +set (the documentation does not tell the reason why the constraint exists +but it exists). + +Thus, only when the MSRs are left unlocked before handover to the OS the +setting of these MSRs can be supported for VM guests. + Debug enclaves --------------
Updated documentation to document the constraint, which prevents emulating the MSR values for VM guests. Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> --- v2: fix typos Documentation/x86/intel_sgx.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)