4

If a server or or PC is running AMD CPUs, will those be affected by the Spectre and/or Meltdown bugs currently effecting Intel chips?

Why or why not?

What makes it affect one and not the other? How does architecture play a role?

TestinginProd
  • 908
  • 3
  • 9
  • 14

3 Answers3

7

Spectre works by causing the CPU to speculatively execute code selected by the attacker in the context of the target process. It does this by getting the branch predictor to guess incorrectly about which way an upcoming branch instruction will go, then looking for side effects of the code whose execution was discarded. Any CPU that performs speculative execution is vulnerable to Spectre, although if the branch predictor is primitive enough (eg. the 68040's "always take the branch" prediction) or doesn't support predicting indirect branches, Spectre is much harder to make use of.

Meltdown works by speculatively reading protected memory. On Intel, the protection status of the memory isn't checked until the CPU decides that yes, the "read protected memory" branch of the execution path is the correct one. In the meantime, observable side effects will have taken place. AMD states that their CPUs check the protection status earlier and are not affected, and the authors of the Meltdown paper say that they were unable to get the attack to work on ARM.

Mark
  • 34,390
  • 9
  • 85
  • 134
  • 1
    Why is speculative execution allowed to bypass memory security? I can understand that an attempt to access non-user memory from speculatively-executed user mode code shouldn't cause a trap, but why not just abandon speculative execution if the memory wouldn't be accessible with current privileges? – supercat Jan 04 '18 at 22:31
  • It's not immediately obvious that speculatively reading protected memory can cause problems -- the direct effects of any such read will be discarded when the branch isn't taken or the processor trap is hit. If you don't realize that the indirect effects can leak information, then continuing execution past the trap and only enforcing the trap once the speculative execution gets turned into real execution is the fast, easy option. – Mark Jan 04 '18 at 23:35
  • Even if the continued speculative execution following a memory fetch didn't create security vulnerabilities, I don't see any reason it would be easier or better than having an invalid fetch force the abandonment of the current speculative path. Having a "this seems dodgy" signal abandon the current speculative path, with no requirement that the signal indicate what was dodgy or be completely free of false positives, would seem easier than trying to keep track of the fact that a speculative fetch was invalid and the processor must trap if it determines that the fetch should have executed. – supercat Jan 04 '18 at 23:48
  • Keep in mind that this bug has apparently been present since 1995. I don't think anyone could have dreamed up all the crazy attacks that we know now in 1995. And since Intel has been iterating on the same extremely complex designs for so long, it's easy to see how something like that might not have been re-visited. – alex.forencich Jan 09 '18 at 05:19
1

First of all, Meltdown only affects Intel CPUs. It is a relatively simple exploit that affects all Intel CPUs with out of order execution, which is most everything since 1997 except for some Atom CPUs.

Regarding Spectre, there is still a lot of confusion out there about what kinds of CPUs are affected by it. There's an article on tenfourfox about PowerPC where it was determined that some older PowerPC chips like the 7447 do not have enough out of order execution to be vulnerable to Spectre. I speculate that older AMD CPUs, such as the K6 or K7 architectures, may also not have enough speculative (out of order execution) abilities to be affected.

For at least one variation of Spectre to work, two instructions must be speculatively executed. The first is a memory access to a location that can be outside of what the program is allowed to access, and then the second is a dependent memory load instruction which uses the data loaded by the first instruction as an address. This requires that two instruction complete all ahead of time. By doing this traces of the address of that second memory read which was based on illegally accessed data from the first memory read is left in the cache and can be slowly extracted using a sort of trial and error timing method. The illegal memory access instruction must occur after a branch which the CPU incorrectly predicts, otherwise the program would crash when that instruction actually executed. When the CPU branches another way than it expected, it just dumps the speculatively executed instructions and continues on, but the cache remains affected by the memory access that those instructions caused.

I'm not an expert on this so there are probably some technical errors but the big picture of what's happening should be correct.

Alex Cannon
  • 402
  • 2
  • 7
0

Shortly: Yes, but not only!

What makes it affect one and not the other? How does architecture play a role?

All this is about some very old CPU conceptuals features! (1st publication I found about speculative execution: Dynamic Schemes for Speculative Execution of Code is dated in 1998! 20 years old!

CPUs constructors use a lot of improvement features, which are documented, but which evolved (mostly by constructor self initiative)... From time to time, by more improvement, some feature could become buggy!

As each constructor implement each conceptual feature by his own way, by physical design, keeping details secrets, from 20 years ago... Running about performances... In fine, for comparable performances, similar weaknesses appear throughout each development branch...

So meltdown wich seem to be a special case of spectre will work under somes implemention, but not on others... But I'm pretty sure, new exploits will appear, who run on others and not on somes...

But that's only my own specultaion!
;-)

Some reading

A simple search for Spectre ARM Intel NVidia on any search engine, will let you find some interesting publications:

And others...

F. Hauri - Give Up GitHub
  • 4,597
  • 2
  • 19
  • 32