New Spectre Vulnerability Beats Mitigations, Performance to Badly Drop After Fix

I agree. I want these turned on for shared servers and on the consumer on OS processes that I don't trust. But I would want an option to turn it off for JavaScript-heavy sites that I do trust.

I'm frankly amazed that the mitigations so far have not already been disastrous to performance. Either we accept drastically less performance from now until basically forever, or we adopt a more fine-grained security model.

PR_SET_SPECULATION_CTRL

People regularly run untrusted Javascript in their browsers. Spectre is exploitable via Javascript as well. There are some mitigations, but those are generally just of the kind "make the timer API suck more" and the likes. Those mitigations don't really fully mitigate the problem and get more and more toothless with new variants of Spectre-like problems.

Spectre and the like needs to be dealt with on everything that isn't strictly an embedded fixed-code device.

Web browsers do. Especially with v8 JIT, ASM.JS, WebAssembly. People have used it in the past to do things like write HTML pages that reach all the way down, across the browser, across docker, across gvisor, across selinux, across the operating system, across the hypervisor, and reprograms your CPU microcode. https://www.usenix.org/system/files/conference/usenixsecurit... I kind of wish browsers provided us the freedom to turn all those wasm jit optimizations off, for that reason. Does anyone know how to write a browser extension that does it? If you want something that should be done for consumer machines, push for ECC RAM.

I will happily sacrifice some performance to be able to run JavaScript, WebAssembly, virtual machines and Docker containers safely on my laptop.

That seems reasonable to me. For especially paranoid people (like some of the HN crowd), you could design a "safe" computer within a computer that takes all the performance hits from in-order cache-less designs and has two very controlled communication channels with the rest of the system: one for bidirectional data transfers to the main CPU and an unidirectional one to stream (software-rendered?) framebuffer data to the GPU.

I highly doubt that the market is big enough to make such a product viable.

You also have to always wonder what the environmental impact of these security fixes is, both in terms of extra carbon pumped into the atmosphere and the resources going into replacement CPUs. It's probably very bad. I wonder whether it's ethical to publish them? :)

I think it depends how broadly you define class of vulnerabilities. As I understand it any processor capable of speculative execution is vulnerable to the broad class of Spectre/Meltdown vulnerabilities, which includes all commonly used processors implementing the ARM instruction set.

The M1 has had a paper recently published about Spectre-like speculative execution exploits, so at least for that class of ARM, yes I believe so

It's probably impossible by a wide margin. The compiler is limited to emitting plain old x86 instructions, the leaky u-ops and caches thereof used to execute essentially harmless x86 instructions instructions are a microprocessor implementation detail.

Sorry but this is false and we must end this misconception. Run JavaScript in a browser on a single-user machine? You are vulnerable.