Jon Masters On Understanding Spectre & Meltdown CPU Vulnerabilities

[TurbulentToothpick]

Ugh... the slides were great, and this could have been a great presentation, but Jon Masters isn't a good presenter. He's nervous, stutters, doesn't know the content, and tells a poor story. I don't think he practiced the talk at all. I have doubts that he understands the technology. It's painful to listen to his level of anxiety. By the end of the talk he's hyperventilating into the microphone.

I hate to criticize him, but he needed to prepare and needs more experience giving presentations like this.

It would be awesome if someone took the slides and did a youtube talk regarding the subject matter.

Also: "Can you please just shut up, thank you" <applause>

Regarding the question of how multiple researchers all came up with the same exploits at the same time: Read this wired article: https://www.wired.com/story/meltdown...law-discovery/

And there was a great unanswered question regarding liability at the end.

[Azrael5]

That's not real. A FSB has nothing to do with these bugs. The only plausible thing I see connecting them is that the original Atom CPUs used a FSB (because it was cheap and old tech) and isn't affected - but that's because it was an in-order design (also because it was cheap and old). Plenty of FSB using CPUs like the Pentium 4 are absolutely at risk for these bugs, because they use speculative execution.

So how to know if own cpus are affected or not? are there a list or a tool to investigate it?

[oskar-n]

Also: "Can you please just shut up, thank you" <applause>

That was because people was starting to leave and talk to each other and disturb the Q & A.

[DrYak]

DrYak I've asked many people and consulted forums which state that cpus base on fsb are immune from those bugs. Is it real or not?

Which "FSB" are you talking about ? "Front Side Bus" ? i.e.: CPUs that happen to have a separate northbridge in their chipset ? As opposed to more recent CPUs that move the memory controller (and some bus controllers like PCIe) into the CPU package ?

Well, by some historical timing coincidence, it happens that CPU makers decided to move the memory controller inside the CPU package at very roughly the same time as they started adding speculative execution to keep their pipeline fed.

But as a said : very roughly.

There are lots of CPU who still used a front side bus but do speculative execution (Intel Pentium 4, AMD K7 Athlon, etc.)

And in the RISC world, there are lots of cores that still don't do any speculative execution despite being entirely self contained SoCs (the list of susceptible CPUs at ARM's website is extremely short).

So the FSB might seem as a rough indicator, but it's very rough, don't count on it.

The appearance of out-of-order execution and very-long pipeline (And thus very high frequency clocks) is a much better indicator.
(But not necessarily: very parallel processors, like server CPUs such as UltraSpace Niagaras, or like anything GPU like Intel Xeon Phi on MIC or Nvidia's CUDA enabled GPU, etc.
all have very long pipe-lines, but never ever do speculative execution. Instead of executing speculatively, they keep the pipeline fed only by having as many thread as possible in flight and doing lots of Multithreading/Hyperthreading)

In practice, it seems SV1 is not easily fixed by microcode alone (and rather will never be done for all of Intel and AMD), plus there wont be a simple, global switch to turn off the spec. execution and willingly taking the performance hit?

Yup. The "fixes" I've seen published about variant 1 are basically firmware assisted way for a compiler to compile a specific section by saying "please do not speculatively execute beyond this peculiar (and very important) check".
But it's not a generic solution, it's tagging a few critical boundary checks here and there.
And most of the fixing goes in actually re-designing a few software in such a way, that it's not critical if a software can be exploited into seeing data which is its own already - so basically leaving the "JIT eBPF" in its default deactivated position, redesigning the JIT Javascript engines, moving extension to WebExtension standard that further enable process separation, etc.

Whereas "retpoline" (basically "return-orient-programmed" constructed, but turned around to actually be used as a defensive tool instead of an attacking tool) are a generic way to do indirect branches that don't lead to speculative execution of dangerous parts. (So a good solution for variant 2 no matter is it is actually exploitable in a CPU or not).

And finally KPTI - kicking the kernel outside of the reachable space whenever code returns back to userspace, not relying on memory protection which might be broken (I'm looking at you, Intel) (and also to the couple of ARM cores that Intel tricked ARM into collaborating about), is definitely a (somewhat) costy generic solution. PCID is a hardware function of recent CPU that brings KPTI for nearly for free (instead of actually kicking the kernel out of the address space, each entry in the cache is tagged with the ID of the process. The userspace process and the kernel have different IDs so their caches cannot be used by the other)

(So KPTI+PCID might even be eventually turned on CPU that aren't meltdown-affected like AMD's and the rest of ARMs ... well basically the rest of the world beside Intel's)

[f.s.e]

Yup. The "fixes" I've seen published about variant 1 are basically firmware assisted way for a compiler to compile a specific section by saying "please do not speculatively execute beyond this peculiar (and very important) check".
But it's not a generic solution, it's tagging a few critical boundary checks here and there.
And most of the fixing goes in actually re-designing a few software in such a way, that it's not critical if a software can be exploited into seeing data ...

In my opinion, not going to happen everywhere, ever. Therefore an unrealistic workaround and a nightmare today ;-) Without a global switch to turn off the spec. execution in e.g. microcode, security is doomed for a long time to come ... eg. how would one recompile code without the code? ROFL

[DrYak]

Without a global switch to turn off the spec. execution in e.g. microcode

Very hard, as speculative execution isn't a feature of the microcode, but a feature of the pipeline.
You'll need a newer generation of CPU designed post-spectre.
(AMD is hinting that this is the case with their Zen 2: they've managed to bake solution against).

But it's anyway the direction we're heading in the long term : more parallelism.
(And thus, easier to keep cores busy by multithreading rather than more complicated tricks).

But it's going to take some time until all the typical workloads are adapted to this.

Until then, speculative execution is a necessary risky evil too show nice numbers on benchmarks.

eg. how would one recompile code without the code? ROFL

By using an OS where the code is available and which is very often recompiled - not only to fix CPU bugs, but simply to leverage better newer compilers.
You know, like running Linux :-D (a rolling distro, tumbleweed to be more precise)

[hawkinsw]

Just FYI: The video for this presentation is now online: https://youtu.be/2kCDPCgjlJ4

Then there is a video from Stanford where he gives the same presentation: https://youtu.be/zuBw1HFJMsM

Enjoy!

[hawkinsw]

Interesting read, correct me if I am wrong here: There is currently no ProofOfConcept which does demonstrate Spectre outside an "in-process" scenario, eg.:

https://github.com/crozone/SpectrePoC

The PoCs seem to be limited to "in-process" designs.

That is a copy/paste of the code from the Spectre paper itself.

[azdaha]

I just realized right now that, AFAICT, in order to take advantage of Spectre exploit, a vulnerability like Meltdown is needed to access the cache. So, as of right now, and as far as we know, AMD processors are not as vulnerable to exploitation, right?

[smitty3268]

I just realized right now that, AFAICT, in order to take advantage of Spectre exploit, a vulnerability like Meltdown is needed to access the cache. So, as of right now, and as far as we know, AMD processors are not as vulnerable to exploitation, right?

Spectre can't be used to exploit the kernel, but it can be used in-process. That's a significant problem for a web-browser, as an attacker website might serve up javascript which could read user passwords from the browser's memory.

It's definitely a much lesser concern than meltdown, though, and particularly for cloud hosting. The concern there would be mostly about chaining multiple attacks together, if you can find other vulnerabilities to exploit.