Intel SGX Enclaves Support For Linux Sent Out For A 29th Time
Going on since 2016 has been the long-running effort getting the Software Guard Extensions (SGX) support into the mainline Linux kernel. Sent out this week was the SGX foundation patches for the twenty-ninth time as it works to get into shape for upstream acceptance.
Every few months tends to bring new rounds of SGX patches but ultimately new issues are pointed out or other code still left to be cleaned up. This work on the Secure Guard Extensions subsystem for the Linux kernel is about providing hardware-protected, encrypted memory regions with SGX enclaves. Intel SGX with Memory Encryption Engines (MEE) have been supported since Skylake CPUs albeit as we are approaching Tiger Lake mobile CPUs and Ice Lake Xeons in the months ahead, this SGX work for the kernel still remains up in the air.
With the 29th round of patches has changes around its self-test, various memory management changes, and other small bits changed.
We'll see if the 29th time is the charm and if this Intel SGX code ends up being accepted for the Linux 5.8 cycle up next or if it will still be a further drawn out process for finally getting this code upstream. Since the debut of SGX in 2015, there still seems to be some enterprise interest in SGX for DRM/secure computing purposes but aside from that interest seems to be somewhat diminished by attacks like LVI, Plundervolt, Spectre, Prime+Probe, and others having at least partial exposure on SGX.
Every few months tends to bring new rounds of SGX patches but ultimately new issues are pointed out or other code still left to be cleaned up. This work on the Secure Guard Extensions subsystem for the Linux kernel is about providing hardware-protected, encrypted memory regions with SGX enclaves. Intel SGX with Memory Encryption Engines (MEE) have been supported since Skylake CPUs albeit as we are approaching Tiger Lake mobile CPUs and Ice Lake Xeons in the months ahead, this SGX work for the kernel still remains up in the air.
Intel 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.
With the 29th round of patches has changes around its self-test, various memory management changes, and other small bits changed.
We'll see if the 29th time is the charm and if this Intel SGX code ends up being accepted for the Linux 5.8 cycle up next or if it will still be a further drawn out process for finally getting this code upstream. Since the debut of SGX in 2015, there still seems to be some enterprise interest in SGX for DRM/secure computing purposes but aside from that interest seems to be somewhat diminished by attacks like LVI, Plundervolt, Spectre, Prime+Probe, and others having at least partial exposure on SGX.
5 Comments