5 ms·

Not really. So far these mostly haven't been able to cross process boundaries, and most browsers have tripled-down on process-sandboxing by this point (iframe s

Not really. So far these mostly haven't been able to cross process boundaries, and most browsers have tripled-down on process-sandboxing by this point (iframe sandboxing was the last major push here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if... ) So process-based sandboxing will continue to be the defense here, and process switching will just get a little bit slower as increasingly more caches are flushed (toss the uOp cache into that list now). For basically all consumer usages this will be perfectly fine. On the other hand, things like Cloudflare's Workers are looking a lot more suspect.

1e-9 6y ago
This is a threat that won’t be fully mitigated until one’s browser is updated to flush the Micro-Op cache. Of course in the meantime, safe browsing practices such as avoiding untrusted Javascript will provide protection. But then, we should always be doing that anyway, so it's not as if this should be changing behavior of the average, security-conscious person. It's just another in an unending series of threats.
kentonv 6y ago
> So far these mostly haven't been able to cross process boundaries Actually, most Spectre vulnerabilities, including this one, do cross process boundaries when they are first discovered, and kernel and microcode patches are needed to implement mitigations against this -- typically flushing some cache or something when switching between kernel and userspace. Often these mitigations hurt performance. > things like Cloudflare's Workers are looking a lot more suspect. Cloudflare Workers uses a completely different approach to Spectre mitigation, based on slowing down observability of side channels to the point that an attack isn't practical. More details here: https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/ https://blog.cloudflare.com/mitigating-spectre-and-other-sec... This approach doesn't target specific forms of speculation and therefore tends to work against the whole class of bugs, including ones that haven't been disclosed yet. The down side is that it requires restricting the programming environment including changes that would be backwards-incompatible for browsers, and it certainly wouldn't work at all with native code. Luckily Cloudflare Workers was able to design for these constraints from the start. I'm the tech lead of Cloudflare Workers, so I may be biased. But, my honest opinion is that the cloud hosts that accept native code are in a much more precarious position than we are.
- deleted 6y ago
  [deleted]

1e-9 6y ago

This is a threat that won’t be fully mitigated until one’s browser is updated to flush the Micro-Op cache. Of course in the meantime, safe browsing practices such as avoiding untrusted Javascript will provide protection. But then, we should always be doing that anyway, so it's not as if this should be changing behavior of the average, security-conscious person. It's just another in an unending series of threats.

kentonv 6y ago

> So far these mostly haven't been able to cross process boundaries Actually, most Spectre vulnerabilities, including this one, do cross process boundaries when they are first discovered, and kernel and microcode patches are needed to implement mitigations against this -- typically flushing some cache or something when switching between kernel and userspace. Often these mitigations hurt performance. > things like Cloudflare's Workers are looking a lot more suspect. Cloudflare Workers uses a completely different approach to Spectre mitigation, based on slowing down observability of side channels to the point that an attack isn't practical. More details here: https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/ https://blog.cloudflare.com/mitigating-spectre-and-other-sec... This approach doesn't target specific forms of speculation and therefore tends to work against the whole class of bugs, including ones that haven't been disclosed yet. The down side is that it requires restricting the programming environment including changes that would be backwards-incompatible for browsers, and it certainly wouldn't work at all with native code. Luckily Cloudflare Workers was able to design for these constraints from the start. I'm the tech lead of Cloudflare Workers, so I may be biased. But, my honest opinion is that the cloud hosts that accept native code are in a much more precarious position than we are.

deleted 6y ago
[deleted]