Upcoming Intel® SGX Features Explained: Improved Virtualization, Configuration Management, and Key Sharing
In an update to the Intel Software Developer’s Manual (SDM), Intel detailed upcoming changes to the Intel® SGX instruction set. The new features improve Enclave Page Cache management in virtualized environments and allow the addition of additional information to sealing key derivation and attestation reports.
The improvements allow for better multi-tenancy with EPC oversubscription and easier configuration and software update management.
I will go into detail on each of these in this post.
EPC Oversubscription
The SGX architecture allows sharing the Enclave Page Cache (EPC) between different VMs. Using static allocations or ballooning to allocate the EPC between VMs is straightforward.
However, if the VM manager (VMM) wants to dynamically allocate EPC pages, it needs to trap (emulate) the OS-level SGX instructions to keep track of the logical relationships between all EPC pages.
This is because the EPC is not just a flat chunk of memory, but the contents are hierarchical. As shown in the following diagram, the pages belonging to an enclave are rooted in an SGX Enclave Control Structure (SECS) page.
When evicting pages from the EPC, a SECS page may not be evicted unless all the other pages belong to that enclave are already evicted. This restriction also applies at the VMM level, even though the VMM doesn’t necessarily know about this structure.
The EPC oversubscription feature set introduces new instructions that allow a VMM to identify the hierarchy of pages. In particular, there is now an OS-level instruction ENCLS[ERDINFO] which will return information about an EPC page.
This information includes its type, permissions and state, and if it’s an enclave page, the guest-physical address of the SECS page. This instruction might be useful for SGX drivers as well. There is also a new root instruction, ENCLV, which has several leaf instructions. A VMM can use it for the new EPC eviction flow.
More details on this topic can be found in the paper Intel SGX Architecture for Oversubscription of Secure Memory in a Virtualized Environment, presented at HASP 2017.
Key sharing and separation (KSS)
People who have been writing applications for SGX will surely have noticed that communicating between or attesting to different but inter-operating applications can be a bit cumbersome. The KSS feature set adds two new mechanisms that allow for more flexibility in this regard: a configuration value and extra product IDs.
The configuration value is a 64-byte ID and a 2-byte Security Version Number (SVN). This SDM calls it the “post-EINIT configuration identity”. Practically, it is a value that does affect the enclave’s identity for attestation and (optionally) sealing key generation but is not included in the enclave signature.
This means a software vendor can have a single enclave binary that can be easily customized at enclave load time. A practical application of this is loading code at enclave runtime while maintaining the ability to separate payloads.
Additionally, a specific customization can be depended on for security purposes. As with all the SVNs, an enclave can recover secrets sealed by a key with the same configuration ID but a lower (and not a higher) configuration SVN.
The extra product IDs are two 16-byte IDs that can be used in sealing key derivation. They are called “family ID” and “extended product ID” but can be used for any purpose. The IDs are included in the SIGSTRUCT, but not in EINITTOKEN, meaning a launch enclave can’t use these values for access control.
The values are attested to but are not part of the target enclave identity in local attestations. Presumably the idea is to use the family ID in conjunction with the signing key to create a space of keys known to multiple specific applications.
Extended product ID can be used in conjunction with product ID to create a larger key space for a particular product. It is no longer required to include the ISVPRODID in the sealing key derivation.
Interestingly, this appears to allow for the generation of a sealing key that is shared amongst all enclaves (of all vendors) on a platform, although the utility of this is unknown.
Conclusion
Both EPC oversubscription and Key sharing and separation make SGX more practical to use. I for one can’t wait to use these features in our SGX applications at Fortanix.
