Intel MPX, CET, SGX, WTF

If you are confused about the different security technologies in modern Intel CPUs, you have come to the right place. I’m going to attempt to give a really brief overview. This is not an in-detail hardcore technical discussion. The goal is just to give a brief informal overview what problem each technology solves.

Intel MPX: Memory Protection Extensions

We live in a world, where an uncomfortable amount of software is written in unsafe programming languages. It would be nice if the CPU with help from the compiler can bounds check memory accesses and take some out of the danger out of running these programs.

With MPX, the compiler generates special MPX bounds check instructions that are NOPs on system not supporting MPX. On systems that do support MPX, you get all the benefits of the CPU checking whether memory accesses are actually touching the memory they are allowed to. The idea is that the software vendor can ship a single binary to everyone and people using MPX-capable CPUs live a more secure life.

Intel MPX is deprecated and support for it is disappearing. The world has decided that software-only methods, such as ASAN and friends do a better job at finding memory unsafety.

Intel CET: Control Flow Enforcement

We live in a world, where an uncomfortable amount of software is written in unsafe programming languages. It would be nice if the CPU with help from the compiler can validate that programs only execute code that they are supposed to execute. Specifically, ROP attacks work by jumping to snippets of executable code that should not actually be jumped to.

Consider an attacker that is able to control the value of a function pointer through a buffer overflow. To ensure that code that uses this function pointer can only jump to known jump targets, the CPU supports a new instruction ENDBR. Jump targets must start with this ENDBR instructions or the CPU will raise an exception. This limits an attack to only jump to valid jump targets instead of freely choosing what code to execute.

Similarly, with CET the CPU also keeps a shadow stack to defend against malicious function return addresses on the stack. In a nutshell, the CPU keeps a inaccessible shadow copy of all return addresses in addition to the normal program stack. When the CPU pops a return address from the stack, the CPU will also consult the shadow stack to see whether the return address was tampered with.

Like MPX, CET is only a bandaid over insecure software and cannot make it secure. CET can only make exploitation hard. As such, CET is a worthwhile tool to protect legacy code, but eventually all that legacy code needs to be rewritten in safer languages.

Intel SGX: Software Guard Extensions

We live in a world, where most code runs on infrastructure that is not trusted by the author of the code. Consider the Digital Restrictions Management (DRM) usecase: A video streaming service wants to prevent users from creating copies of videos they have paid for. Another (better) usecase is holding on to secret keys even when the system where these keys are used on is fully exploited. Maybe you want to keep your crypto keys for yourself, even if the cloud provider that runs your code is untrustworthy.

SGX allows creation of “enclaves” whose state live in encrypted memory (when it is not currently in registers or various CPU caches). These enclaves only have distinct entry and exit points to the “insecure” world around it. Otherwise, they are a black box. The main selling point is that even the operating system kernel cannot peek into enclaves. The OS is still in control of executing enclaves, though, so SGX cannot guarantee availability. It does a good job at protecting integrity and confidentiality of data in enclaves (caveats below).

Of course, you cannot use the now untrusted operating system to load any secrets into enclaves. For this SGX, enables the usual Trusted Computing concepts, such as Remote Attestation (proving to other systems that the enclave runs a specific set of software on a real Intel CPU) and Sealed Storage (storing data in a way so that only the “right” enclave can access it). With this an enclave can prove its legitimacy to a server over the network, receive crypto material and keep it safe.

SGX was hit in the nuts pretty hard by the whole lot of CPU vulnerabilities. Check out Foreshadow, Plundervolt, Load Value Injection, …

Besides the hardware security issues, there are also unique attack methods that would not be in the attacker model for other technologies. Because the operating system can freely schedule enclaves how it wants, enclaves can be effectively single-stepped. Single-stepping enclaves allows for fine grained observation of changes to microarchitectural state. This in turn allows attackers to leak secrets from enclaves when they use libraries that are vulnerable to these kinds of attacks.

Let’s leave the security issues behind and look at the programmer experience. The enclave programming model is involved. You have to create something like RPC entry points into your enclave code. And code that runs in enclaves, is not magically secure. So any vulnerability in your enclave code can be used to exfiltrate any secrets the enclave tries to protect.

In addition, SGX only works on operating systems that are SGX enabled. Linux only recently gained support for SGX, for example. If you don’t target Linux or Windows, there’s no SGX for you.

So all in all there is a lot of caveats to this Intel-only security feature that might not warrant the large investment in architecting software for SGX.

So if you are betting the bank on keeping secrets, you might be better served with well-understood technologies, such as smartcards or hardware security modules (HSMs).

For those that still want to venture into trusted execution environments, such as SGX, it’s advised to choose an abstraction that takes some of the pain away and also allows to target competing technologies by other vendors. One example is Enarx.

Upcoming

Next time, I’ll discuss Intel MKTME and TDX. Do you have questions or suggestions for other Intel CPU technologies to write about? Ping me on Twitter.

Update 2021-11-14

I’ve revised the SGX section and incorporated feedback from msw regarding SGX security.