According to Google’s JavaScript team; Spectre mitigation doomed to failure

Fortunately or unfortunately, our offensive research advanced much faster than our defensive research, and we quickly discovered that software mitigation of all possible leaks due to Spectre was infeasible. This was due to a variety of reasons. First, the engineering effort diverted to combating Spectre was disproportionate to its threat level. In V8 we face many other security threats that are much worse, from direct out-of-bound reads due to regular bugs (faster and more direct than Spectre), out-of-bound writes (impossible with Spectre, and worse) and potential remote code execution (impossible with Spectre and much, much worse). Second, the increasingly complicated mitigations that we designed and implemented carried significant complexity, which is technical debt and might actually increase the attack surface, and performance overheads. Third, testing and maintaining mitigations for microarchitectural leaks is even trickier than designing gadgets themselves, since it’s hard to be sure the mitigations continue working as designed. At least once, important mitigations were effectively undone by later compiler optimizations. Fourth, we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software, even after a heroic effort by our partners at Apple to combat the problem in their JIT compiler.

Click to expand...

Grimlaking said:

Sigh... AMD?

Click to expand...

Grimlaking said:

Sigh... AMD?

Click to expand...

schoolslave said:

So stop bloating websites with mountains of fragile and cobbled together Javascript frameworks and libraries?
I find it disingenuous to refer to security mitigations as "tech debt" and make no mention of the bullshit that is the "modern" web.

Click to expand...

jardows said:

I think this sums up your argument quite well:

http://www.commitstrip.com/en/2019/04/19/its-better-with-javascript/

View attachment 157081

Click to expand...