Hi! > Documentation of the features of the Software Guard eXtensions used > by the Linux kernel and basic design choices for the core and driver > and functionality. > --- /dev/null > +++ b/Documentation/x86/intel_sgx.rst > @@ -0,0 +1,201 @@ > +=================== > +Intel(R) SGX driver > +=================== > + > +Introduction > +============ > + > +Intel(R) SGX is a set of CPU instructions that can be used by applications to > +set aside private regions of code and data. The code outside the enclave is > +disallowed to access the memory inside the enclave by the CPU access control. > +In a way you can think that SGX provides inverted sandbox. It protects the > +application from a malicious host. Spelling out "Software Guard eXtensions" somewhere around here would be nice. As would be notice that due to Spectre / Meltdown / L1TF / ... this sandboxing functionality does not really work on any CPU that is on the market today. > +Enclave can only execute code inside the ELRANGE. Instructions that may cause > +VMEXIT, IO instructions and instructions that require a privilege change are > +prohibited inside the enclave. Interrupts and exceptions always cause enclave > +to exit and jump to an address outside the enclave given when the enclave is > +entered by using the leaf instruction ENCLS(EENTER). > +Launch control > +-------------- > + > +To launch an enclave, two structures must be provided for ENCLS(EINIT): > + > +1. **SIGSTRUCT:** signed measurement of the enclave binary. > +2. **EINITTOKEN:** a cryptographic token CMAC-signed with a AES256-key called > + *launch key*, which is re-generated for each boot cycle. > + > +The CPU holds a SHA256 hash of a 3072-bit RSA public key inside > +IA32_SGXLEPUBKEYHASHn MSRs. Enclaves with a SIGSTRUCT that is signed with this > +key do not require a valid EINITTOKEN and can be authorized with special > +privileges. One of those privileges is ability to acquire the launch key with > +ENCLS(EGETKEY). > + > +**IA32_FEATURE_CONTROL[17]** is used by the BIOS configure whether > +IA32_SGXLEPUBKEYHASH MSRs are read-only or read-write before locking the > +feature control register and handing over control to the operating system. Would it be possible to explain what this means? Basically my BIOS decides what enclaves I can run? Who generates the EINITTOKENs and can my code get one? What other priviledges does signed SIGSTRUCT give to the enclave? > +Launching enclaves > +------------------ > + > +The current kernel implementation supports only unlocked MSRs i.e. > +FEATURE_CONTROL_SGX_LE_WR must be set. The launch is performed by setting the > +MSRs to the hash of the public key modulus of the enclave signer, which is one > +of the fields in the SIGSTRUCT. Aha, so in current kernel implementation kernel decides what enclaves I can run? Anyway, all this is "interesting reading" but not really suitable for system administrator who is not expert in Intel CPUs. Do we need some kind of explanation for ARM kernel hackers, system administrators and other interested parties? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
