5 ms·

Does that really follow? That purely software based solutions are doomed because hardware based solutions failed? Wasn't most fixes done at least partially in s

Does that really follow? That purely software based solutions are doomed because hardware based solutions failed? Wasn't most fixes done at least partially in software?

kllrnohj 8y ago
I think you misunderstood. The hardware-based solutions are being fixed with various approaches whereas the software-based solutions nobody has any clue how to fix. So much so that Chrome is giving up on software-isolation entirely and is rolling out even more process-based sandboxing https://www.chromium.org/Home/chromium-security/site-isolation https://www.chromium.org/Home/chromium-security/site-isolati...
- andreiw 8y ago
  Depends on how you define hardware and software. There are global workarounds that amount to crippling CPU behavior, to provide guarantees for code not written to be spectre safe. I guess that’s what you mean by “hardware”. But “software” approaches are localized mitigations to code written to avoid spectre attacks - and these localized mitigations use arch specific sequences to do so.
  - microcolonel 8y ago
    Another major problem with the software level mitigations is that they cost considerably more. Speculation fences cut performance to a small integer fraction of prior performance.
    - andreiw 8y ago
      Then tell your SiP to do better. On Arm the conditional speculation barrier couldn’t be more lightweight (CSDB).
- pjmlp 8y ago
  Process-based sandboxing was too heavy in old hardware systems, but on modern ones is the best approach. Threads and plugins have proven not to be the best ideas regarding implementing safe systems.
  - microcolonel 8y ago
    > Process-based sandboxing was too heavy in old hardware systems, but on modern ones is the best approach. They actually started first with full process isolation, then realized that it had an outsize impact on performance, and now they're going back because the consequences for security are now known. There have been spectre-related patches going into chromium and v8 for the last few months, and they just keep coming, it's hard to overstate how much work must be done to have a decent probability of not being exposed to the known variants of these bugs in a software isolated system.

Does that really follow? That purely software based solutions are doomed because hardware based solutions failed? Wasn't most fixes done at least partially in software?

kllrnohj 8y ago

I think you misunderstood. The hardware-based solutions are being fixed with various approaches whereas the software-based solutions nobody has any clue how to fix. So much so that Chrome is giving up on software-isolation entirely and is rolling out even more process-based sandboxing https://www.chromium.org/Home/chromium-security/site-isolation https://www.chromium.org/Home/chromium-security/site-isolati...

andreiw 8y ago
Depends on how you define hardware and software. There are global workarounds that amount to crippling CPU behavior, to provide guarantees for code not written to be spectre safe. I guess that’s what you mean by “hardware”. But “software” approaches are localized mitigations to code written to avoid spectre attacks - and these localized mitigations use arch specific sequences to do so.
- microcolonel 8y ago
  Another major problem with the software level mitigations is that they cost considerably more. Speculation fences cut performance to a small integer fraction of prior performance.
  - andreiw 8y ago
    Then tell your SiP to do better. On Arm the conditional speculation barrier couldn’t be more lightweight (CSDB).
pjmlp 8y ago
Process-based sandboxing was too heavy in old hardware systems, but on modern ones is the best approach. Threads and plugins have proven not to be the best ideas regarding implementing safe systems.
- microcolonel 8y ago
  > Process-based sandboxing was too heavy in old hardware systems, but on modern ones is the best approach. They actually started first with full process isolation, then realized that it had an outsize impact on performance, and now they're going back because the consequences for security are now known. There have been spectre-related patches going into chromium and v8 for the last few months, and they just keep coming, it's hard to overstate how much work must be done to have a decent probability of not being exposed to the known variants of these bugs in a software isolated system.