Glider from the game of Life, rising from the left

Unity

Archives

Blogroll

Topic: #hardware-design

Still More Spectre Variants

2018-05-22⊺11:23:52-05:00

Almost all processors speculatively pre-execute a load instruction when they anticipate that any store instructions that precede it will not affect the contents of the memory location from which the value is loaded. The pre-execution is cancelled and discarded if this condition turns out to be false. Like other kinds of speculative execution, this one turns out to have side effects that can be detected and exploited by attackers to exfiltrate data from memory locations to which they should not have access.

“Speculative Execution, Variant 4: Speculative Store Bypass”
Jann Horn, Monorail, Project Zero, February 6, 2018
https://bugs.chromium.org/p/project-zero/issues/detail?id=1528

“Side-Channel Vulnerability Variants 3a and 4”
United States Computer Emergency Readiness Team, May 22, 2018
https://www.us-cert.gov/ncas/alerts/TA18-141A

“Spectre Chip Security Vulnerability Strikes Again; Patches Incoming”
Steven J. Vaughn-Nichols, Zero Day, May 22, 2018
https://www.zdnet.com/article/spectre-chip-security-vulnerability-strikes-again-patches-incoming

#spectre #hardware-design #security

The Discovery of BranchScope

2018-03-28⊺09:52:54-05:00

Researchers have discovered another vulnerability in the Spectre family. Like Spectre, it exposes side effects of speculative execution of instructions. Whereas Spectre extracted the information from the cache, the new attack, called BranchScope, extracts it from the directional predictor, which is the component of the branch-prediction unit inside the processor.

The directional predictor is updated each time a conditional branch instruction is executed, even speculatively, and maintains an estimate of the likelihood that the condition will be true the next time the same conditional branch instruction is executed. It leaks information because its state is modified during speculative execution and not restored afterward if the speculative execution path turns out not to have been the correct one.

“BranchScope: A New Side-Channel Attack on Directional Branch Predictor”
Dmitry Evtyushkin, Ryan Riley, Nael Abu-Ghazaleh, and Dmitry Ponomarev, Proceedings of the 23rd ACM International Conference on Architectural Support for Programming Languages and Operating Systems, March 24, 2018
http://www.cs.ucr.edu/~nael/pubs/asplos18.pdf

“As Predicted, More Branch Prediction Processor Attacks Are Discovered”
Peter Bright, Ars Technica, March 26, 2018
https://arstechnica.com/gadgets/2018/03/its-not-just-spectre-researchers-reveal-more-branch-prediction-attacks/

#spectre #BranchScope #hardware-design

Spectre is a General Strategy, Not a Specific Vulnerability

2018-01-17⊺14:58:45-06:00

The general strategy exploits a design weakness in which the processing of instructions under some security condition has a side effect that is observable even when that condition is not met. Attackers can often combine observations of these side effects with publicly available information to make inferences about the activity of the processor and the contents of registers, caches, or memory. Out-of-order speculative execution is just one such design weakness, and cache use is just one of the exploitable side effects.

“Speculation Considered Harmful?”
“Nemo”, Cryptography mailing list, January 16, 2018
http://www.metzdowd.com/pipermail/cryptography/2018-January/033684.html

Even if you eliminate speculative execution entirely, the cache still holds “footprints” of the execution of your privileged code. And it is hard to prove exactly what information that conveys (or does not convey).

There are two kinds of security. One is where you say “I do not see how an attacker can do X.” The other is where you say “I can prove the attacker cannot do X, assuming Y and Z.” The former leaves you vulnerable to people smarter and/or more motivated than you. The latter is what you want.

Cache timing attacks, given the implicit management of the cache by the CPU hardware, means that I do not know exactly what information I am leaking from privileged code no matter how I write that code.

And it is not just the cache. Consider performance counters, debug registers, register renaming (i.e. vastly more physical registers than architectural registers), etc. All of this implicitly-managed state might carry who-knows-what information across protection domains. …

To prove that nothing interesting passes across protection domains, given all those megabytes of implicitly managed state … is going to require some serious rethinking of CPU architecture.

#spectre #hardware-design

Hashtag index

This work is licensed under a Creative Commons Attribution-ShareAlike License.

Atom feed

John David Stone (havgl@unity.homelinux.net)

created June 1, 2014 · last revised December 10, 2018