Every Intel CPU to be 5–30% slower once this issue is patched


(Greg Robson) #1

Awkward doesn’t really cover it… :grimacing:


(Greg Robson) #2

Obligatory “Well that escalated quickly…”

This is going to have implications for anyone using the cloud as this thread shows on AWS. Some instances with average/peak load of 50%/75% before the fix are now seeing 75%/95% after… so they are going to have to increase their instance size (and costs) as a result.

The likes of Air BnB (who use 10s of thousands of servers from the last article I read) are going to find their bills going up significantly!


(Jon) #3

This is really interesting - it is a bug that is forcing us to rethink some fundamental security assumptions. I had one service provider say to me that, theoretically, it means that code inside Linux containers, and possibly even traditional VMs, can reach outside of their usual memory boundaries. That wasn’t supposed to happen :pouting_cat:


(Stuart Langridge) #4

It’s worse than that. JavaScript in the browser can read all your memory for every process. Kudos to the browser teams for fixing this (by removing access to the high-performance timers), but I don’t think we’ve seen the end of this class of bugs, either from browser-to-kernel, from app-to-kernel, from container to hypervisor, and so on…


(Jon) #5

Oh dear! I’d heard that browser JS was vulnerable in some fashion, but I didn’t know it was that bad. I wonder if, to achieve some defence-in-depth, people will start being more choosy about what JS they run, over and above installing NoScript and other similar plugins.


(Greg Robson) #6

It has been a rough start to 2018 for devops :grimacing:

I see Linode has teamed up with other major players to try and get the issue fixed sooner on their platform.
https://blog.linode.com/2018/01/03/cpu-vulnerabilities-meltdown-spectre/


(Jon) #7

Here’s a paper on this class of JavaScript timer vulnerabilities. I’ve scan-read it and not really grokked it, I think I need to read it several times to get a handle on it. But for everyone else’s delectation…


(Andy Wootton) #8

The boundaries were made of software and the bug is in hardware, so it can limbo under them? :slight_smile:


(Greg Robson) #9

@halfer A few people have come up with some interesting metaphors to help explain the issue. The librarian scenario is quite good:

The fixes seem to have varying effects on the CPU :open_mouth: - I think my PC received updates recently and I’ve had a couple of blue screens in the last couple of days.

Some very different experiences of the CPU usage increase depending on usage scenario.


(Jon) #10

Well, I can accept that running specific machine-level code (even in a container or VM) can trick a processor into divulging information it should not. What I think is most confusing is how JavaScript timers in a browser sandbox can be used to do the same thing. I’d have thought that JS is so far away from the processor that it would not be possible to do that.


(Andy Wootton) #11

It’s about parallel pipelines isn’t it? The crack is to take over a speculative execution. I’d imagine the timers are used to delay execution and hijack the other pipe, which flows out of the sandbox.

A couple of hours ago I was reading about Clojure’s concurrency mechanisms. It demonstrated why functions mustn’t have side-effects, by demonstrating how the unknown execution order might cause code to be re-started when there are collisions, so state change statements may be repeated. It’s not hard to imagine that might be exploitable.