Comment by msbarnett | Hacker News Reader

Comment by msbarnett | Hacker News Reader

Parent Full thread

https://v8.dev/blog/spectre

> 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.

> Our research reached the conclusion that, in principle, untrusted code can read a process’s entire address space using Spectre and side channels. Software mitigations reduce the effectiveness of many potential gadgets, but are not efficient or comprehensive.

The “some variants” include MDS, which the author was aware of but which were not at the time of publication out of embargo.

But they do not claim that hardware mitigations are necessary. They claim that they need to change browser architecture a little bit:

> The only effective mitigation is to move sensitive data out of the process’s address space. Thankfully, Chrome already had an effort underway for many years to separate sites into different processes to reduce the attack surface due to conventional vulnerabilities. This investment paid off, and we productionized and deployed site isolation for as many platforms as possible by May 2018.

So with improved browsers it's still unclear why ordinary users need those performance-eating mitigations, when browser vendors managed to solve that problem themselves.

These vulnerabilities can jump process address space boundaries. It's a lot harder but can be done, look at the original Spectre paper: https://spectreattack.com/spectre.pdf

> But they do not claim that hardware mitigations are necessary. They claim that they need to change browser architecture a little bit

For Spectre, that’s enough; for Spectre-class Intel permission exploit vectors (aka, Meltdown, Fallout, ZombieLoad, RIDL, Store to Leak Forwarding and other MDS vulnerabilities) all of the same infeasability of browser mitigations apply but data also leaks across process boundaries, so process isolation does jack shit to protect you without lower level mitigations.

There’s nothing whatsoever browsers can do to prevent this. Process memory read isolation effectively doesn’t exist in the presence of unpatched Intel MDS vulnerabilities.

> So with improved browsers it's still unclear why ordinary users need those performance-eating mitigations, when browser vendors managed to solve that problem themselves.

The unclarity is only in your misunderstanding of the relationship of MDS vulnerabilities on Intel to Spectre vulnerabilities in general.

Reply on news.ycombinator.com