What does SGX 2.0 (scalable SGX) sacrifice (e.g., removing integrity tree) in security for better performance （e.g., large EPC size)?

[bronzeMe]

Some documents stated that SGX 2.0 (or scalable SGX) cannot support memory integrity protection, is it right? is there some official document that makes clear comparison between SGX1.0 and SGX2.0 from the respective of security and performance?

Thanks.

[ScottR-Intel]

Hello.

If you read our Software Developer's Manuals, the "SGX2" term only refers to/means one feature: Enclave Dynamic Memory Management. This feature allows an enclave to add more enclave memory after it has already been loaded/instantiated. SGX2 is not just a Scalable feature, as our latest Xeon E-2300 series also has it.

Our 3rd Generation Xeon Scalable CPUs (aka Ice Lake Server - "ICX") did switch to using a technology called Total Memory Encryption - Multi-Key (TME-MK) (Whitepaper) that uses AES-XTS, moving away from the Memory Encryption Engine that the consumer and Xeon E CPUs used. This allowed us to massively increase the possible EPC size (up to 512GB/CPU) as well as gain a big increase in performance. More info about SGX on our multi-package, Scalable platforms here.

Scott

[bronzeMe]

@ScottR-Intel Thank you so much. So, Xen Scalable SGX using TME-MK to increase EPC size, but loss memory integrity protection tree (e.g., Merkle tree), which cannot defeat hardware-based replay attacks (e.g. memory bus replay attack)

[bennetyee]

Hi @ScottR-Intel

In "original" SGX physical security boundary was packaging. So Intel is part of the TCB. With "scalable SGX" the security model essentially must assume that the motherboard manufacturer will not be doing aliasing/memory replay, so now the TCB must include such vendors. The mobo could be custom (cloud instances) and is not part of any attestation measurements. Is this a fair summary?