4 ms·

If you had control over the ISA, and were jitting code as you would with WASM, couldn't you defeat Spectre 1 with an instruction that essentially introduces a m

If you had control over the ISA, and were jitting code as you would with WASM, couldn't you defeat Spectre 1 with an instruction that essentially introduces a masked region that the processor will not read or speculate outside of until the mode is disabled? If the attacker controls the instruction stream it's game over (since they can disable the mask), but if they're just writing wasm that generates malicious speculative in process loads, it would prevent that. Then an attack would have to trick library calls in to doing the same job, which is certainly possible, but much harder. Of course this would negate many of the benefits of staying in the same process, so I'm not necessarily saying it's a good idea.

mdriley 6y ago
When you say "control over the ISA", I'll assume you mean "precise control over the emitted instructions". In which case: yes! That's Speculative Load Hardening (https://llvm.org/docs/SpeculativeLoadHardening.html https://llvm.org/docs/SpeculativeLoadHardening.html). SLH tries to squash side-channels by preventing any speculatively-loaded data from being forwarded to dependent instructions until proving that branch prediction followed the right path. But this undoes a lot of the performance that microarchitectures have added through branch prediction, since dependent memory loads (think linked list entries, or C++ vtables) are stalled behind full resolution of the branch condition. If you're doing nontrivial compute, you can end up ahead performance-wise by splitting the computation into a separate process and invoking it via IPC. Now you don't need SLH because the untrusted process doesn't have long-lived secrets in its address space.
- reitzensteinm 6y ago
  No, I mean specifically if you're building your own CPUs and can add instructions. You add the ability to set a hardware mask that all values are passed through before they're used as addresses for loads and stores including speculation. Loads and stores that fall outside the masked region will simply wrap around. In your JIT, you enter and leave this mode before and after running user code to ensure it can't escape its region. This would be a lot of work to pull off and would require custom hardware and software, but (at least as far as I can tell) it should work.
  - gpderetta 6y ago
    This is basically segments. It would work as long as your implementation doesn't have Meltdown-like vulnerabilities, i.e. speculation past hardware enforcend protection. We know it can be done because there are high performance CPUs which are not vulnerable to Meltdown.
titzer 6y ago
The answer is that are too many different kinds of speculative leaks to defeat them all via masking. For example, the supervisor code (i.e. the code of the Wasm Engine) has access to the broader address space, by design. This code can be tricked in various ways (in speculation) into performing out-of-bounds reads and disclosing that information in ways that is detectable by user programs.
- reitzensteinm 6y ago
  Right, you have to trick the outside world to perform the speculation for you. In the case of a web browser, you're not going to plug all those holes. But in some cases, you probably could make it absolutely bulletproof. The closer to data->data transforms you get, the better. For example, if you wanted a router that could run WASM blobs that make routing decisions. You pass in a header byte array and receive back route information. Designed correctly, it's not a given that there is any surface area for an attacker to read data from a neighbour's address space.
  - titzer 6y ago
    > But in some cases, you probably could make it absolutely bulletproof. I don't believe this. Not on modern hardware. I worked on Spectre for almost two years while at Google. We wrote this: https://arxiv.org/abs/1902.05178 https://arxiv.org/abs/1902.05178
    - reitzensteinm 6y ago
      Well, your years of study are worth much more than my idle speculation, so after browsing your paper I'll happily accept that you're right. But my intuition is that the instructions themselves executed under such a masking system are no more able to perform timing attacks on the rest of the process than arbitrary code from one process can perform timing attacks on another. If there's something specific I'm missing there I'd love to know what it is so I can update my mental model.

mdriley 6y ago

When you say "control over the ISA", I'll assume you mean "precise control over the emitted instructions". In which case: yes! That's Speculative Load Hardening (https://llvm.org/docs/SpeculativeLoadHardening.html https://llvm.org/docs/SpeculativeLoadHardening.html). SLH tries to squash side-channels by preventing any speculatively-loaded data from being forwarded to dependent instructions until proving that branch prediction followed the right path. But this undoes a lot of the performance that microarchitectures have added through branch prediction, since dependent memory loads (think linked list entries, or C++ vtables) are stalled behind full resolution of the branch condition. If you're doing nontrivial compute, you can end up ahead performance-wise by splitting the computation into a separate process and invoking it via IPC. Now you don't need SLH because the untrusted process doesn't have long-lived secrets in its address space.

reitzensteinm 6y ago
No, I mean specifically if you're building your own CPUs and can add instructions. You add the ability to set a hardware mask that all values are passed through before they're used as addresses for loads and stores including speculation. Loads and stores that fall outside the masked region will simply wrap around. In your JIT, you enter and leave this mode before and after running user code to ensure it can't escape its region. This would be a lot of work to pull off and would require custom hardware and software, but (at least as far as I can tell) it should work.
- gpderetta 6y ago
  This is basically segments. It would work as long as your implementation doesn't have Meltdown-like vulnerabilities, i.e. speculation past hardware enforcend protection. We know it can be done because there are high performance CPUs which are not vulnerable to Meltdown.

titzer 6y ago

The answer is that are too many different kinds of speculative leaks to defeat them all via masking. For example, the supervisor code (i.e. the code of the Wasm Engine) has access to the broader address space, by design. This code can be tricked in various ways (in speculation) into performing out-of-bounds reads and disclosing that information in ways that is detectable by user programs.

reitzensteinm 6y ago
Right, you have to trick the outside world to perform the speculation for you. In the case of a web browser, you're not going to plug all those holes. But in some cases, you probably could make it absolutely bulletproof. The closer to data->data transforms you get, the better. For example, if you wanted a router that could run WASM blobs that make routing decisions. You pass in a header byte array and receive back route information. Designed correctly, it's not a given that there is any surface area for an attacker to read data from a neighbour's address space.
- titzer 6y ago
  > But in some cases, you probably could make it absolutely bulletproof. I don't believe this. Not on modern hardware. I worked on Spectre for almost two years while at Google. We wrote this: https://arxiv.org/abs/1902.05178 https://arxiv.org/abs/1902.05178
  - reitzensteinm 6y ago
    Well, your years of study are worth much more than my idle speculation, so after browsing your paper I'll happily accept that you're right. But my intuition is that the instructions themselves executed under such a masking system are no more able to perform timing attacks on the rest of the process than arbitrary code from one process can perform timing attacks on another. If there's something specific I'm missing there I'd love to know what it is so I can update my mental model.