Awkward doesn’t really cover it…
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!
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
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.
It has been a rough start to 2018 for devops
I see Linode has teamed up with other major players to try and get the issue fixed sooner on their platform.
The boundaries were made of software and the bug is in hardware, so it can limbo under them?
@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 - 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.
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.