5 ms·

Flushing on privilege level change is just the Meltdown mitigation. Spectre includes reading data in the same process.

deleted 9y ago
[deleted]
Tuna-Fish 9y ago
The meltdown mitigation is to move the OS to a different namespace, and flush the TLB between changes. Spectre comes in two varieties, the generic branch avoidance "boundary check bypass", and the BTB poisoning one. The solution to boundary check bypass is to just surrender and document branches as unsuitable for providing security boundaries. Going forward, "branch on out of bounds" is going to be replaced by using unconditional math to clamp access to the array boundary. In any case, this is of very marginal utility to an attacker, because it's only useful if there is some privileged information within an address space where the attacker gets to write code. Really only useful in JIT situations, and those will be quickly fixed in software. The other half of spectre, the BTB poisoning, is much more scary, as it allows you to inject arbitrary code to an arbitrary process (or kernel!) running on the same CPU. (The limitation is that you only get to run until the branch reaches retirement, and you can only communicate with the rest of the world through cache timing.) This one will be hotfixed by retpolines in software, then fixed by ucode changes that provide options to flush the BTB, and in the long term fixed in hardware by tagging BTB entries better.
- Polyisoprene 9y ago
  My browser process can read plenty of sensitive information and with js and now streaming wasm JIT increasing the attack vector, I’m not so sure I trust the “quickly fixed in software” :) Yeah, BTB tagging is probably a lot better than flushing performance wise.
  - Tuna-Fish 9y ago
    The quick fix is pointer poisoning and sanitizing pointers before access. For example, if the code of a JS array does p%arraylength before using p, it makes the spectre 1 vulnerability impossible to exploit. Browsers with JIT engines are also very quickly patched software, and afaict all the major browsers have fast-tracked changes to prevent spectre 1. At this point, spectre 1 is no longer a major threat. In any case, many people are misinformed that disabling speculation is a viable fix. It really isn't -- completely disabling speculation means that every branch has a cost of ~20 cycles and serializes execution around it. Current normal x86 code executes a branch every 5-10 instructions (generally, more when using dynamic languages, less when using static compiled-to-metal languages). Executing branches so often doesn't ruin performance because branch predictor hit rates are >95%, as most of those branches are basically guards, type checks and the like which are almost never taken. Disabling speculation would make modern high-end CPUs spend the vast majority of their time just waiting for the branches to resolve. There is no, and can be no hardware fix to this. The only solution is just to accept that you cannot use a branch alone to protect secret data.
- hansendc 9y ago
  Meltdown mitigations do not flush the TLB when changing from kernel to/from user when the PCID feature is in place. That's basically everywhere from Haswell on (for Linux and Windows), and in some places as early as Nehalem (>= 4.9 kernels on Linux, not Windows).

deleted 9y ago

[deleted]

The meltdown mitigation is to move the OS to a different namespace, and flush the TLB between changes. Spectre comes in two varieties, the generic branch avoidance "boundary check bypass", and the BTB poisoning one. The solution to boundary check bypass is to just surrender and document branches as unsuitable for providing security boundaries. Going forward, "branch on out of bounds" is going to be replaced by using unconditional math to clamp access to the array boundary. In any case, this is of very marginal utility to an attacker, because it's only useful if there is some privileged information within an address space where the attacker gets to write code. Really only useful in JIT situations, and those will be quickly fixed in software. The other half of spectre, the BTB poisoning, is much more scary, as it allows you to inject arbitrary code to an arbitrary process (or kernel!) running on the same CPU. (The limitation is that you only get to run until the branch reaches retirement, and you can only communicate with the rest of the world through cache timing.) This one will be hotfixed by retpolines in software, then fixed by ucode changes that provide options to flush the BTB, and in the long term fixed in hardware by tagging BTB entries better.

Polyisoprene 9y ago
My browser process can read plenty of sensitive information and with js and now streaming wasm JIT increasing the attack vector, I’m not so sure I trust the “quickly fixed in software” :) Yeah, BTB tagging is probably a lot better than flushing performance wise.
- Tuna-Fish 9y ago
  The quick fix is pointer poisoning and sanitizing pointers before access. For example, if the code of a JS array does p%arraylength before using p, it makes the spectre 1 vulnerability impossible to exploit. Browsers with JIT engines are also very quickly patched software, and afaict all the major browsers have fast-tracked changes to prevent spectre 1. At this point, spectre 1 is no longer a major threat. In any case, many people are misinformed that disabling speculation is a viable fix. It really isn't -- completely disabling speculation means that every branch has a cost of ~20 cycles and serializes execution around it. Current normal x86 code executes a branch every 5-10 instructions (generally, more when using dynamic languages, less when using static compiled-to-metal languages). Executing branches so often doesn't ruin performance because branch predictor hit rates are >95%, as most of those branches are basically guards, type checks and the like which are almost never taken. Disabling speculation would make modern high-end CPUs spend the vast majority of their time just waiting for the branches to resolve. There is no, and can be no hardware fix to this. The only solution is just to accept that you cannot use a branch alone to protect secret data.
hansendc 9y ago
Meltdown mitigations do not flush the TLB when changing from kernel to/from user when the PCID feature is in place. That's basically everywhere from Haswell on (for Linux and Windows), and in some places as early as Nehalem (>= 4.9 kernels on Linux, not Windows).