Speculation Attack Against Intel's SGX
Another speculative-execution attack against Intel’s SGX.
At a high level, SGX is a new feature in modern Intel CPUs which allows computers to protect users’ data even if the entire system falls under the attacker’s control. While it was previously believed that SGX is resilient to speculative execution attacks (such as Meltdown and Spectre), Foreshadow demonstrates how speculative execution can be exploited for reading the contents of SGX-protected memory as well as extracting the machine’s private attestation key. Making things worse, due to SGX’s privacy features, an attestation report cannot be linked to the identity of its signer. Thus, it only takes a single compromised SGX machine to erode trust in the entire SGX ecosystem.
News article.
The details of the Foreshadow attack are a little more complicated than those of Meltdown. In Meltdown, the attempt to perform an illegal read of kernel memory triggers the page fault mechanism (by which the processor and operating system cooperate to determine which bit of physical memory a memory access corresponds to, or they crash the program if there’s no such mapping). Attempts to read SGX data from outside an enclave receive special handling by the processor: reads always return a specific value (-1), and writes are ignored completely. The special handling is called “abort page semantics” and should be enough to prevent speculative reads from being able to learn anything.
However, the Foreshadow researchers found a way to bypass the abort page semantics. The data structures used to control the mapping of virtual-memory addresses to physical addresses include a flag to say whether a piece of memory is present (loaded into RAM somewhere) or not. If memory is marked as not being present at all, the processor stops performing any further permissions checks and immediately triggers the page fault mechanism: this means that the abort page mechanics aren’t used. It turns out that applications can mark memory, including enclave memory, as not being present by removing all permissions (read, write, execute) from that memory.
EDITED TO ADD: Intel has responded:
L1 Terminal Fault is addressed by microcode updates released earlier this year, coupled with corresponding updates to operating system and hypervisor software that are available starting today. We’ve provided more information on our web site and continue to encourage everyone to keep their systems up-to-date, as it’s one of the best ways to stay protected.
I think this is the “more information” they’re referring to, although this is a comprehensive link to everything the company is saying about the vulnerability.
Subscribe to comments on this entry
L • August 16, 2018 12:26 PM
Perhaps companies will finally start migrating to open-source hardware. RISC-V anyone?
I can envision a future where there are multitudes of custom chips rather than just a few general purpose, high-volume chips.
The problem with custom chips though is of course, the economics of production. However, I could also envision companies offering open-source hardware production as a service for other companies.
In other words, SAAS (software as a service), except instead of offering software, these companies would be offering help in building custom open-source hardware chips, making the economics of production a much smaller obstacle.
RISC-V could potentially take this from hypothetical to reality.