| Message ID | 20170616152530.25196-1-jarkko.sakkinen@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jun 16, 2017 at 05:25:30PM +0200, Jarkko Sakkinen wrote: > I implemented fallback mechanism for the driver in the last Fall > originally because I had to drop all BUG_ON() usage. The driver > gracefully fallbacks from failing ENCLS in any situation. > > It turns out that this could happen in a VM guest even if the > driver is working correctly. This patch adds to the documentation > an explanation how we fallback after the host has woken up in a > VM guest. > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > --- > Documentation/x86/intel_sgx.rst | 38 ++++++++++++++++++++++++++------------ > 1 file changed, 26 insertions(+), 12 deletions(-) > > diff --git a/Documentation/x86/intel_sgx.rst b/Documentation/x86/intel_sgx.rst > index 71026732af61..ee7fe9487d7b 100644 > --- a/Documentation/x86/intel_sgx.rst > +++ b/Documentation/x86/intel_sgx.rst > @@ -77,29 +77,43 @@ 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. > > +Debug enclaves > +-------------- > + > +Enclave can be set as a *debug enclave* of which memory can be read or written > +by using the ENCLS(EDBGRD) and ENCLS(EDBGWR) opcodes. The Intel provided launch > +enclave provides them always a valid EINITTOKEN and therefore they are a low > +hanging fruit way to try out SGX. > + > Virtualization > +============== > + > +Launch control > -------------- > > 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. > +MSRs, trap ENCLS(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). > +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 > --------------- > +Suspend and resume > +------------------ > > -Enclave can be set as a *debug enclave* of which memory can be read or written > -by using the ENCLS(EDBGRD) and ENCLS(EDBGWR) opcodes. The Intel provided launch > -enclave provides them always a valid EINITTOKEN and therefore they are a low > -hanging fruit way to try out SGX. > +If the host suspends and resumes, the enclave memory for the VM guest could > +become invalid. This can make ENCLS leaf operations suddenly fail. > + > +The driver has a graceful fallback mechanism to manage this situation. If any of > +the ENCLS leaf operations fail, the driver will fallback by kicking threads out > +of the enclave, removing the TCS entries and marking enclave as invalid. After > +this no new pages can be allocated for the enclave and no entry can be done. > > SGX uapi > ======== > -- > 2.11.0 > Merged. /Jarkko
diff --git a/Documentation/x86/intel_sgx.rst b/Documentation/x86/intel_sgx.rst index 71026732af61..ee7fe9487d7b 100644 --- a/Documentation/x86/intel_sgx.rst +++ b/Documentation/x86/intel_sgx.rst @@ -77,29 +77,43 @@ 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. +Debug enclaves +-------------- + +Enclave can be set as a *debug enclave* of which memory can be read or written +by using the ENCLS(EDBGRD) and ENCLS(EDBGWR) opcodes. The Intel provided launch +enclave provides them always a valid EINITTOKEN and therefore they are a low +hanging fruit way to try out SGX. + Virtualization +============== + +Launch control -------------- 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. +MSRs, trap ENCLS(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). +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 --------------- +Suspend and resume +------------------ -Enclave can be set as a *debug enclave* of which memory can be read or written -by using the ENCLS(EDBGRD) and ENCLS(EDBGWR) opcodes. The Intel provided launch -enclave provides them always a valid EINITTOKEN and therefore they are a low -hanging fruit way to try out SGX. +If the host suspends and resumes, the enclave memory for the VM guest could +become invalid. This can make ENCLS leaf operations suddenly fail. + +The driver has a graceful fallback mechanism to manage this situation. If any of +the ENCLS leaf operations fail, the driver will fallback by kicking threads out +of the enclave, removing the TCS entries and marking enclave as invalid. After +this no new pages can be allocated for the enclave and no entry can be done. SGX uapi ========
I implemented fallback mechanism for the driver in the last Fall originally because I had to drop all BUG_ON() usage. The driver gracefully fallbacks from failing ENCLS in any situation. It turns out that this could happen in a VM guest even if the driver is working correctly. This patch adds to the documentation an explanation how we fallback after the host has woken up in a VM guest. Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> --- Documentation/x86/intel_sgx.rst | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-)