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.

Posted on August 16, 2018 at 11:43 AM • 17 Comments

Comments

LAugust 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.

justinacolmenaAugust 16, 2018 12:31 PM

Intel's instruction set is too complex, and the microprocessor lacks sufficient general purpose registers to avoid unnecessary spillage, and to make matters worse, it already uses RISC microcode internally to "interpret" the CISC instructions. We need to strip out the CISC layer and move to a straight RISC architecture in order to mitigate these risks to general data integrity and security.

Let's not try to get so cute with the execution of low-level machine instructions.

Martin BonnerAugust 16, 2018 2:12 PM

@justincolmena : Arm has speculative execution too. The problem is that people want their old code to work on new chips. If the next generation chip makes the pipeline deeper, you have to make the branch delay slot be *two* instructions - or you have to add speculative execution.

echoAugust 16, 2018 2:18 PM

@justinacolmena

When I was at school I learned passable 6502 machine code on the BBC Micro. I later glanced at ARM on the Archimedes running RiscOS but neverwent further. When I became half serious about learning Intel assembler this was around the time when Intel was exploding the size of their instruction set. It was ridiculously large so I swore off it before trying. I later learned of allegations that Intel stuff their instruction set for marketing reasons. Maybe to make life difficult for competitors too?

Without being able to learn the basics and get a good grounding it is fruitless for children to begin learning especially today when everything is locked down. This may put of future generations who have the know how not only to make things but also question what is going on behind the scenes.

Ditto all these bloated languages which don't make sense (C/C++!!!!) and here today gone tomorrow bloated frameworks and proprietory graphics API of the week.

WeatherAugust 16, 2018 3:30 PM

Doesn't Intel x86 only have about 80 instructions,shore instruction like Bound don't be need,but it can check [reg] for access to none mapped virtual memory,and add a value to eax,if you just used Moved,the program would crash and She wouldn't help

WeatherAugust 16, 2018 3:31 PM

Doesn't Intel x86 only have about 80 instructions,shore instruction like Bound don't be need,but it can check [reg] for access to none mapped virtual memory,and add a value to eax,if you just used Mov ,the program would crash and Seh wouldn't help

HmmAugust 16, 2018 5:12 PM

"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."

Can they fully close off that problem with microcode update + Hypervisor?

Or are they just putting a sarcophagus over Chernobyl?

AnonAugust 16, 2018 5:54 PM

Maybe I missed something, but if removing ALL permissions bypasses the security checks, what the heck is going on? Is a read/fetch NOT made to the bogus address, but the cache data (containing the SGX data) returned as if it was?

@echo: my thoughts exactly, though I disagree you can't learn. I learned x86 assembler, and about 20 key instructions were required to do so. Only if you get into the processor extensions do things get wild.

It's still possible to do what you want with just the basic processor and FPU, even if it is not the fastest or most efficient code. I still got within ~2% of an optimizing compiler for execution time, and I hadn't really even tried to make the code fast through hand-optimized tricks!

just meAugust 16, 2018 11:45 PM

I'd never even heard of SGX until this episode, but:

"... it only takes a single compromised SGX machine to erode trust in the entire SGX ecosystem."

That sounds to me like a catastrophically inadequate security model.

VRKAugust 17, 2018 11:52 AM

@Bruce

the

"comprehensive link to everything the company is saying"
seems to be corrupted by virtue of a single quote at the start of the first link.

Hence:

"[you] 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.

which are the same link, no?


Thanks for the heads up.


Clive RobinsonAugust 17, 2018 4:24 PM

@ justinacolmena, echo, others,

Intel's instruction set is too complex, and the microprocessor lacks sufficient general purpose registers to avoid unnecessary spillage

The IAx86 ISA was designed to be mnemonic (not binary) compatable to the much earlier 8080 8bit processor that was the foundation stone of the CP/M OS that was the "business" OS of desktop and low cost centralised systems.

If you actually examine the binary translation of the assembler instructions you find as was common back then that "bit fields" for register and memory mapping were three bit octets not four bit nibbles.

Many people not realising this get overly worked up brcause their tool chain works with nibbles and bytes etc so they don't get to see the simplicity of the mapping functions at the 8088/6 level.

All the other instructions Intel later bolted in can be done with the earlier instructions. The reason they did this was to get more performance across the CPU-System "memory and address busses". Whilst the mapping of these is more complex they can be easily seen in binary.

But one of the problems as always is "backwards compatability" few people now remember let alone use CP/M and VisiCalc etc, but their influance from a third of a century ago is still seen via the IAx86 ISA. If you regard 12-18 months as a generation in computing thats 20-30 generations which in human terms would take you back to the birth of Francis Bacon[1] in the reign of Elizabeth the 1st of England who was having a little dust up with a relative Mary Queen of Scots. Which has given us the first detailed goings on of the "Black Chamber" and it's cryptanalysis activities. Which is important from the history of security asspect as it showed that simple substitution ciphers then widely beleived to be secure were anything but.

[1] https://en.m.wikipedia.org/wiki/Francis_Bacon_(philosopher)

echoAugust 17, 2018 8:02 PM

@Clive

Not to mention John Dee who was wrapped up in the history of the Voynich manuscript. Another alchemist before he was retroactively named a scientist was Newton. Margaret Cavendish wrote a number of works including observations of the experimental work of Bacon.

I remember using CP/M and Wordstar. Crikey! And those floppy discs used to make a racket. As for IBM PCs booting DOS... Hmmmm! Beep! Bbrrrraaaaappp BRaaaaaaap. Chick. Chick. Chick. Brrrrrrrrrp. Zzzzzzzzzzz. Dut dut dut.

And now we have solid state which goes like this...


Yes. Boring isn't it?

justinacolmenaAugust 17, 2018 8:34 PM

Wordstar

I remember MultiMate and later, WordPerfect. There was something that ran on an early Apple Macintosh, but I forget.

Anymore, I use LaTeX or some derivative of TeX, because otherwise the autocorrect clobbers anything technical I try to write about.

A red squiggly line is not enough. Modern word processors tend to force autocorrection and make it all but impossible to turn off.

Clive RobinsonAugust 18, 2018 5:53 AM

@ echo,

Yes. Boring isn't it?

You need to use it as inspiration and write a song... But you'll have to call it something other than "The Sound of Silence" ;-)

More importantly, quiet as it is it should be faster to boot, but guess what it's actually slower...

Now that is what you call progress NOT!!!

echoAugust 18, 2018 9:48 AM

@Clive

I was, like, wuh? Then, "Yeah" once you add all the bloat and latency of modern OS. What do they put in there? Delay loops they can fiddle with to claim the next version is better? I know they have their reasons but like any organisation in the state or privatesector have their reasons for bloat and latency but whatdo they do? Like, effectively?

OS News linked to this blog article on the 8087.

http://www.righto.com/2018/08/inside-die-of-intels-8087-coprocessor.html
Inside the die of Intel's 8087 coprocessor chip, root of modern floating point

@justinacolmena

Import/export hasn't improved much over the years either.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.