Today's summary is about a paper written by Andrew Baumann (Microsoft Research) in 2017.
The slowing pace of Moore’s Law will make it harder to sell CPUs: absent improvements in microarchitecture, they won’t be substantially faster, nor substantially more power eﬃcient, and they will have about the same number of cores at the same price point as prior CPUs. Why would anyone buy a new CPU? One reason to which Intel appears to be turning is features: if the new CPU implements an important ISA extension—say, one required by software because it is essential to security—consumers will have a strong reason to upgrade.
These attacks exploit vulnerabilities in unsafe code like buﬀer overﬂows, but rather than directly injecting executable code, manipulate the program’s control-ﬂow to execute legitimate instructions in an unintended context.
CET consists of two mechanisms: a shadow stack, and indirect branch tracking:
At its core, a shadow stack is a straightforward mechanism: on a function call, the processor saves the return address on both the regular and shadow stacks. The shadow stack stores only return addresses, and is inaccessible to normal code.
On a return, the addresses from both stacks are popped and compared, and an exception raised if they diﬀer, defeating ROP.
The advantage of CET compared to software implementations of shadow stacks is performance, compatibility and security: by modifying the semantics of CALL and RET instructions, no program mod-iﬁcations are needed, and the shadow stack can be made easily and cheaply inaccessible to software through the use of a new page table attribute which protects shadow stacks from access by regular loads and stores.
CET also includes indirect branch tracking to prevent misdirection of function pointers: after an indirect JMP or CALL, an exception is raised unless the next instruction is a valid programmer-intended branch target, as signiﬁed by a new form of NOP instruction. While this is not full control-ﬂow integrity , it restricts the available gadgets.
Similarly, the paper describes how CET adds complexity because of the way it interacts/modifies existing instructions/features.
Sustainability: Given the rate of change + complexity, criticality of the x86 ISA, and particularly given the complex interactions between recent features, the paper questions whether the core x86 promise of indeﬁnite backwards compatibility across many implementations is sustainable.
Timescales: Since they depend on deploying new CPUs, ISA features are slow to be adopted. Example: The original SGX speciﬁcation was published in 2013, but the ﬁrst CPUs to implement it didn’t ship until late 2015, and at the time of writing [the paper] (early 2017) server-class CPUs with SGX support are yet to appear.
Hardware is the new software: From a careful reading of Intel patents, some researchers conclude that SGX instructions are implemented entirely in microcode. This is logical from an engineering perspective:
The paper posit an alternative future with the ultimate goal of decoupling new ISA features from the underlying hardware. Two strategies were proposed.
Security: A key selling point for many recent security features, SGX in particular, is that no software is trusted. Does the implementation of these features in microcode change this? We argue that microcode is more reliable than current software, but not as inherently secure as we might assume.
The paper calls for a rethink of how we approach the instruction set.
It’s time to rethink the notion of an instruction set. It’s no longer the boundary between hardware and software, but rather just another translation layer in the stack.