Computing desk
< January 4	<< Dec \| January \| Feb >>	January 6 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 5

How does Spectre (security vulnerability) works?

I do not really understand what I read about this. I can parse what I read as two different stories about how this works (or maybe I am conflicting two different ideas), but either makes me suspect a giant fault in CPU architecture design (giant as in "no idiot could possibly have greenlighted this, let alone a team of experts"). What is the correct parsing of available info?

Story #1

A legitimate program sends to the CPU a thread that looks like:

if (some condition){
// access some secret info (that the thread is allowed to access, but not a random other thread)
// do some stuff with that info
}
else {
// do other stuff
}

The CPU decides to do speculative execution and execute the first branch of the if clause before seeing how the condition actually evaluates. A malicious thread started by Mallory can then pick up differences via various side-channels, including reading a shared cache or observing how much time was spent in the speculative execution (timing attack).

My question is: how does speculative execution matter to this? If cache is shared between threads, or if the contents of the secret impact execution time, surely this is the case whether the branch is executed on-the-regular or speculatively. (Unless the design of speculative execution implicitly assumes that shared cache could be used for speculative operations, since "it will eventually be cleaned up", yet normal operations do not use such shared cache, because obviously this could lead to cross-thread info leaking; in which case, I contend that was a very, very, very stupid assumption from the get-go.)

Story #2

Mallory crafts and runs a malicious piece of code similar to above:

if (some condition crafted to trigger speculative execution){
// access some secret info that Mallory's thread is not allowed to read
// do some stuff with that info designed to leak via side-channels
}

They do not have the permission level to access the info needed in the if clause, but when executing speculatively, the CPU decides to ignore checking permission levels because it does not want to throw an exception within a speculative branch, and fetches the data anyways. The CPU does not directly return the info because it will clean up after the condition is evaluated, but Mallory can retrieve it anyways by side channels.

My question is: can the CPU even do that (ignore premission levels)? Who thought it would be a good idea that speculative execution could do this? I get that the speculative branch will probably execute differently because of reasons, but it is essentially sandboxing, and IMO should never ever be able to make more reads than would be allowed within a regular execution - authorization tests should fail by default. Tigraan^{Click here to contact me} 12:59, 5 January 2018 (UTC)[reply]

You should read the original paper linked in our Spectre article. The details are rather complicated and I can't do them justice here. But to answer a couple of your questions, speculative execution is involved because one of the tricks involves passing an out of bound index to some code that accesses an array. The code of course compares the value to the array size and won't use it if it's out of bounds, but during speculative execution the result of the comparison is not yet known, so the CPU may access the out of bound value (which may be a secret not intended to be accessible outside the program) and load it into the CPU cache. A second timing trick is then used to determine the cache value. None of this requires a shared cache between threads or violation of permissision levels, and the conditional code in question is not crafted by the attacker, but already exists in the victim program. The attacker merely passes crafted input to the victim program. CodeTalker (talk) 19:01, 5 January 2018 (UTC)[reply]