5 ms·

+1 for pointing at the irony but it's not really true. 1. Hardware design flaws are not irremediable and will be fixed in time. 2. It's still very useful to r

+1 for pointing at the irony but it's not really true. 1. Hardware design flaws are not irremediable and will be fixed in time. 2. It's still very useful to run software that is trusted to not be malicious and/but not trusted to be void of memory bugs.

wbl 8y ago
Not without a big performance hit most servers don't need because they don't cross security domains.
- monocasa 8y ago
  There's been remote Spectre exploits. https://lwn.net/Articles/761100/ https://lwn.net/Articles/761100/
gok 8y ago
Wasmjit doesn't really address #2. Memory bugs in nginx will continue to corrupt data and potentially allow RCE, they just will not be allowed to spread to the rest of the kernel (in theory)
- johncolanduoni 8y ago
  If wasmjit is sound, it won’t allow general RCE. WASM enforces a significant level of control flow integrity; for the most part the worst you can do with an indirect branch is take advantage of type confusion to execute an unintended function. You cannot generate arbitrary code, or use something like return oriented programming to execute portions of existing functions.
kllrnohj 8y ago
> Hardware design flaws are not irremediable and will be fixed in time. There's no particular reason to believe this. Neither Intel nor AMD have committed to any form of side-effect-free speculative execution or similar. That'd required a rather large chunk of transistors and die space, and if nobody is footing the bill for it it's not going to happen. Preventing side-effects from leaking between processes (and ring levels) entirely at the hardware level is definitely going to happen. Within a process, though? That's not going to happen without multiple major players demanding it. Since nearly all the major CPU consumers are currently happy with process boundaries being the security enforcement zones, there's no particular reason to believe that in-process sandboxing will ever have hardware fixes to prevent spectre attacks.
- microcolonel 8y ago
  > Preventing side-effects from leaking between processes (and ring levels) entirely at the hardware level is definitely going to happen. Within a process, though? That's not going to happen without multiple major players demanding it. Since nearly all the major CPU consumers are currently happy with process boundaries being the security enforcement zones, there's no particular reason to believe that in-process sandboxing will ever have hardware fixes to prevent spectre attacks. I do not think there is the degree of distinction between "processes" and "threads" that you think there is. If tools exist to isolate speculation state between processes, those tools can probably also isolate threads in a process.
  - kllrnohj 8y ago
    Of course there is. Threads share page tables, processes don't. Literally the exact distinction between threads & processes in userspace is the one that exists in hardware, too.
    - monocasa 8y ago
      Processes share the higher half of the page tables at least partially, even with KPTI turned on.
- monocasa 8y ago
  > That's not going to happen without multiple major players demanding it. Since nearly all the major CPU consumers are currently happy with process boundaries being the security enforcement zones, there's no particular reason to believe that in-process sandboxing will ever have hardware fixes to prevent spectre attacks. The amount of untrusted code running in browser is only increasing over time, and the CPU vendors have absolutely noticed this. That's why ARMv8.3A added an instruction that literally has JavaScript in it's name (FJCVTZS) for instance. Once you have mitigations for colocating trusted and untrusted code in ring 3, doing the same in ring 0 almost certainly isn't a big deal.
  - kllrnohj 8y ago

wbl 8y ago

Not without a big performance hit most servers don't need because they don't cross security domains.

monocasa 8y ago
There's been remote Spectre exploits. https://lwn.net/Articles/761100/ https://lwn.net/Articles/761100/

gok 8y ago

Wasmjit doesn't really address #2. Memory bugs in nginx will continue to corrupt data and potentially allow RCE, they just will not be allowed to spread to the rest of the kernel (in theory)

johncolanduoni 8y ago
If wasmjit is sound, it won’t allow general RCE. WASM enforces a significant level of control flow integrity; for the most part the worst you can do with an indirect branch is take advantage of type confusion to execute an unintended function. You cannot generate arbitrary code, or use something like return oriented programming to execute portions of existing functions.

kllrnohj 8y ago

> Hardware design flaws are not irremediable and will be fixed in time. There's no particular reason to believe this. Neither Intel nor AMD have committed to any form of side-effect-free speculative execution or similar. That'd required a rather large chunk of transistors and die space, and if nobody is footing the bill for it it's not going to happen. Preventing side-effects from leaking between processes (and ring levels) entirely at the hardware level is definitely going to happen. Within a process, though? That's not going to happen without multiple major players demanding it. Since nearly all the major CPU consumers are currently happy with process boundaries being the security enforcement zones, there's no particular reason to believe that in-process sandboxing will ever have hardware fixes to prevent spectre attacks.

microcolonel 8y ago
> Preventing side-effects from leaking between processes (and ring levels) entirely at the hardware level is definitely going to happen. Within a process, though? That's not going to happen without multiple major players demanding it. Since nearly all the major CPU consumers are currently happy with process boundaries being the security enforcement zones, there's no particular reason to believe that in-process sandboxing will ever have hardware fixes to prevent spectre attacks. I do not think there is the degree of distinction between "processes" and "threads" that you think there is. If tools exist to isolate speculation state between processes, those tools can probably also isolate threads in a process.
- kllrnohj 8y ago
  Of course there is. Threads share page tables, processes don't. Literally the exact distinction between threads & processes in userspace is the one that exists in hardware, too.
  - monocasa 8y ago
    Processes share the higher half of the page tables at least partially, even with KPTI turned on.
monocasa 8y ago
> That's not going to happen without multiple major players demanding it. Since nearly all the major CPU consumers are currently happy with process boundaries being the security enforcement zones, there's no particular reason to believe that in-process sandboxing will ever have hardware fixes to prevent spectre attacks. The amount of untrusted code running in browser is only increasing over time, and the CPU vendors have absolutely noticed this. That's why ARMv8.3A added an instruction that literally has JavaScript in it's name (FJCVTZS) for instance. Once you have mitigations for colocating trusted and untrusted code in ring 3, doing the same in ring 0 almost certainly isn't a big deal.
- kllrnohj 8y ago