Messages in this thread | | | Subject | Re: [PATCH v29 00/20] Intel SGX foundations | From | Jordan Hand <> | Date | Wed, 6 May 2020 09:39:55 -0700 |
| |
On 4/21/20 2:52 PM, Jarkko Sakkinen wrote: > 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. > > There is a new hardware unit in the processor called Memory Encryption > Engine (MEE) starting from the Skylake microacrhitecture. BIOS can define > one or many MEE regions that can hold enclave data by configuring them with > PRMRR registers. > > The MEE automatically encrypts the data leaving the processor package to > the MEE regions. The data is encrypted using a random key whose life-time > is exactly one power cycle. > > The current implementation requires that the firmware sets > IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately the kernel can > decide what enclaves it wants run. The implementation does not create > any bottlenecks to support read-only MSRs later on. > > You can tell if your CPU supports SGX by looking into /proc/cpuinfo: > > cat /proc/cpuinfo | grep sgx > > v29: > * The selftest has been moved to selftests/sgx. Because SGX is an execution > environment of its own, it really isn't a great fit with more "standard" > x86 tests. > > The RSA key is now generated on fly and the whole signing process has > been made as part of the enclave loader instead of signing the enclave > during the compilation time. > > Finally, the enclave loader loads now the test enclave directly from its > ELF file, which means that ELF file does not need to be coverted as raw > binary during the build process. > * Version the mm_list instead of using on synchronize_mm() when adding new > entries. We hold the write lock for the mm_struct, and dup_mm() can thus > deadlock with the page reclaimer, which could hold the lock for the old > mm_struct. > * Disallow mmap(PROT_NONE) from /dev/sgx. Any mapping (e.g. anonymous) can > be used to reserve the address range. Now /dev/sgx supports only opaque > mappings to the (initialized) enclave data. > * Make the vDSO callable directly from C by preserving RBX and taking leaf > from RCX. >
Tested with the Open Enclave SDK on top of Intel PSW. Specifically built the Intel PSW with changes to support /dev/sgx mapping[1] new in v29.
Tested-by: Jordan Hand <jorhand@linux.microsoft.com>
[1] https://github.com/intel/linux-sgx/pull/530
| |