SGX2 support for CPUs that already support SGX1

[Hirschoff__Lina]

Hello,

I am using the Intel Core i7-6700 CPU for SGX development. The CPU supports SGX1 instructions.

Will SGX2 be available for this CPU in the future? Will every CPU that supports SGX1, eventually also support SGX2?

At the moment, querying CPUID with EAX=12H indicates that opcodes of SGX2 instructions are not supported. 

The SGX functionality also depends on the BIOS configuration - we deployed the most recent BIOS update and also asked HP for a BIOS Update that enables SGX2.

I am also interested if anyone in this forum already got his hands on a CPU that supports SGX2.

Thank you and have a great day!

Lina

[AArya2]

Great question. Such a shame it's unanswered.

I second this: What are the oldest models that will in the future support SGX2?

[Dr__Greg]

Good morning to everyone.

Yes, it would seem that SGX2 and its availability are the two most closely held secrets in technology.  I suspect the lack of information around the technology is a function of the politics which seem to surround SGX in general.  This may be compounded by the fact that there are likely SGX 'haves' and 'have nots' in the industry.

With respect to the notion of being able to upgrade an SGX1 machine to have SGX2 capabilities, I'm afraid the answer to that is going to be no.  Most basically, SGX2 is an additional set of leaf instructions added to the ENCLU and ENCLS instruction classes that allow implementation of Enclave Dynamic Memory Management (EDMM).  Implementing this capability requires platform interventions in excess of what can be implemented by a 'BIOS upgrade'.

Part of the confusion surrounding SGX2 is the fact that, inside of Intel, 'SGX2' may be as much of a marketing and product differentiation issue as it is a technology. Loosely speaking SGX2 is or will be a combination of any of the following technologies:

1. Enclave dynamic memory management support (EDMM).
2. Unlocked identity modulus signature registers, ie. Flexible Launch Control.
3. Increased Processor Reserved Memory (PRM) aperture sizes.
4. Multi-socket support
5. Virtualization support.

SGX2 capable platforms will likely be a combination of one or more of the above capabilities, which will in turn depend on the platform and its SKU class.

Currently there is hardware beginning to emerge which supports the SGX2 leaf instructions.  We have a NUC7CJYH in our lab, which is based on the Gemini Lake SOC, that advertises SGX2 instruction support in its SGX CPUID leaf instructions.  We haven't had time to dig too deeply into this hardware, due to deadlines on other issues, but there is little doubt the hardware will execute the EAUG, EBLOCK and EMOD* instructions needed to implement EDMM. There has been guidance for some time from Russian sources, go figure on security technology, that the follow on Apollo SOC has SGX support which will undoubtedly be SGX2 in nature.

One of the important things to note about the Gemini Lake SGX2 capable hardware is that the maximum PRM aperture is 128 megabytes, the same as current SGX1 hardware.  So this is an example of the notion that 'SGX2' support will be a combination of capabilities, the most minimum of which will be support for the extended ENCLS and ENCLU leaf instructions.

Flexible launch control is support for the generation of initialization tokens which allow enclaves to run in non-debug mode without the need for an Intel signing key to be in the loop.  This is one of the features that will undoubtedly be included in the SGX2 support cohort but has no technical requirement on the new leaf instructions.  It is also one of the political hot button issues surrounding SGX in general.

There is a significant likelihood that increased PRM apertures, virtualization support and, of course, multi-socket support will be reserved for higher end XEON server SKU's.  The biggest enigma in the SGX field is if and when multi-socket support will become available.  Given that one of the most significant capabilities advertised for SGX is to run secure workloads in the 'cloud', the lack of any significant guidance on multi-socket platforms has been a bit bewildering.

So that is the situation on SGX2 as we understand it.

The lack of basic guidance on SGX2 hardware support is hard to understand.  There has been work on EDMM support for the Linux kernel driver for almost a year.  Given that the first hardware in the wild was a NUC, I suspect the driver work was probably done on this platform.  It is hard to understand why there would not be general guidance available on when this support would be available.

The latest round of driver support talks about per-node EPC which indicates NUMA and hence multi-socket support.  There is either hardware that this is being developed on or the driver is being written on 'spec', based only on guidance from the SDM and/or other sources.  Which, if the latter is true, indicates a go cautious approach when hardware does become available... :-)

The lack of guidance is a general concern but what is most problematic, from our perspective, is the amount of code churn in the SDK/PSW in order to support hardware that does not exist and on which clear guidance on availability is not being provided.  There was a major and largely incompatible enclave metadata change made in the transition from the 1.9 to 2.0 releases of the SDK in order to support EDMM.  The Intel model in all this is to always upgrade to the latest version of the runtime but that flies in the face of how the industry qualifies platforms. where the mantra, particularly with respect to security, is verify and then maintain.

This produces a model where, in order to run enclaves with TCB compliant SVN's, requires upgrades to run software for which no hardware is available.  At a minimum, what should have been done, is to have production enclaves which were built with version 1.9 metadata in order to provide a long term maintenance path.

Hopefully all of the above is useful guidance.

Have a good day.

Dr. Greg

[AArya2]

Thanks Greg. The terribly weak developer support on this fascinating product is quite disheartening.

[Rd3]

Dr. Greg wrote:

Good morning to everyone.

Yes, it would seem that SGX2 and its availability are the two most closely held secrets in technology.  I suspect the lack of information around the technology is a function of the politics which seem to surround SGX in general.  This may be compounded by the fact that there are likely SGX 'haves' and 'have nots' in the industry.

With respect to the notion of being able to upgrade an SGX1 machine to have SGX2 capabilities, I'm afraid the answer to that is going to be no.  Most basically, SGX2 is an additional set of leaf instructions added to the ENCLU and ENCLS instruction classes that allow implementation of Enclave Dynamic Memory Management (EDMM).  Implementing this capability requires platform interventions in excess of what can be implemented by a 'BIOS upgrade'.

Part of the confusion surrounding SGX2 is the fact that, inside of Intel, 'SGX2' may be as much of a marketing and product differentiation issue as it is a technology. Loosely speaking SGX2 is or will be a combination of any of the following technologies:

1. Enclave dynamic memory management support (EDMM).
2. Unlocked identity modulus signature registers, ie. Flexible Launch Control.
3. Increased Processor Reserved Memory (PRM) aperture sizes.
4. Multi-socket support
5. Virtualization support.

SGX2 capable platforms will likely be a combination of one or more of the above capabilities, which will in turn depend on the platform and its SKU class.

Currently there is hardware beginning to emerge which supports the SGX2 leaf instructions.  We have a NUC7CJYH in our lab, which is based on the Gemini Lake SOC, that advertises SGX2 instruction support in its SGX CPUID leaf instructions.  We haven't had time to dig too deeply into this hardware, due to deadlines on other issues, but there is little doubt the hardware will execute the EAUG, EBLOCK and EMOD* instructions needed to implement EDMM. There has been guidance for some time from Russian sources, go figure on security technology, that the follow on Apollo SOC has SGX support which will undoubtedly be SGX2 in nature.

One of the important things to note about the Gemini Lake SGX2 capable hardware is that the maximum PRM aperture is 128 megabytes, the same as current SGX1 hardware.  So this is an example of the notion that 'SGX2' support will be a combination of capabilities, the most minimum of which will be support for the extended ENCLS and ENCLU leaf instructions.

Flexible launch control is support for the generation of initialization tokens which allow enclaves to run in non-debug mode without the need for an Intel signing key to be in the loop.  This is one of the features that will undoubtedly be included in the SGX2 support cohort but has no technical requirement on the new leaf instructions.  It is also one of the political hot button issues surrounding SGX in general.

There is a significant likelihood that increased PRM apertures, virtualization support and, of course, multi-socket support will be reserved for higher end XEON server SKU's.  The biggest enigma in the SGX field is if and when multi-socket support will become available.  Given that one of the most significant capabilities advertised for SGX is to run secure workloads in the 'cloud', the lack of any significant guidance on multi-socket platforms has been a bit bewildering.

So that is the situation on SGX2 as we understand it.

The lack of basic guidance on SGX2 hardware support is hard to understand.  There has been work on EDMM support for the Linux kernel driver for almost a year.  Given that the first hardware in the wild was a NUC, I suspect the driver work was probably done on this platform.  It is hard to understand why there would not be general guidance available on when this support would be available.

The latest round of driver support talks about per-node EPC which indicates NUMA and hence multi-socket support.  There is either hardware that this is being developed on or the driver is being written on 'spec', based only on guidance from the SDM and/or other sources.  Which, if the latter is true, indicates a go cautious approach when hardware does become available... :-)

The lack of guidance is a general concern but what is most problematic, from our perspective, is the amount of code churn in the SDK/PSW in order to support hardware that does not exist and on which clear guidance on availability is not being provided.  There was a major and largely incompatible enclave metadata change made in the transition from the 1.9 to 2.0 releases of the SDK in order to support EDMM.  The Intel model in all this is to always upgrade to the latest version of the runtime but that flies in the face of how the industry qualifies platforms. where the mantra, particularly with respect to security, is verify and then maintain.

This produces a model where, in order to run enclaves with TCB compliant SVN's, requires upgrades to run software for which no hardware is available.  At a minimum, what should have been done, is to have production enclaves which were built with version 1.9 metadata in order to provide a long term maintenance path.

Hopefully all of the above is useful guidance.

Have a good day.

Dr. Greg

Hi Dr. Greg,

Does this mean current SGX cpu can support Flexible launch control with BIOS update in the future? Since new instruction extension is not needed.

I am looking for a server that support Flexible launch control to deploy DCAP. Do you have any suggestion or links?

Thanks!

Rd