4 ms·

> What needs to die is the belief that you can rely on just software (i.e. memory safety) for isolation between trusted and untrusted code[1]. I don't understa

by twtw 8y ago

> What needs to die is the belief that you can rely on just software (i.e. memory safety) for isolation between trusted and untrusted code[1]. I don't understand how you came to this conclusion. How does spectre indicate that you can't rely on software for isolation? > meltdown bypasses hardware protection, but that's Intel specific It's not Intel specific. Certain ARM and POWER architectures are also vulnerable. Spectre bypasses hardware protections too, just in a more subtle way.

gizmo686 8y ago
The idea behind spectre is that speculative execution bypasses software protections. Given if f(A) B else C, one cannot safely assume that B only gets executed when A resolves to true. It is not reasonable to expect programmers to produce safe code in an environment where they have to doubt if statements. This could be solved without any major overhauls in hardware, by just updating it to make speculative execution actually speculative and not commit any side effects until it knows it went down the correct branch.
- gpderetta 8y ago
  Unfortunately fetching a new cache line from memory is a globally visible side effect. One of the major benefits of speculation and is that it enables additional memory level parallelism. Even otherwise strictly in order designs, when aiming for high performance incorporate some form of memory speculation (scout threading, run ahead execution).
  - gizmo686 8y ago
    Right, and CPUs could, in principle, fix this. Eg. they could speculatively fetch the cache line, and only commit it to the cache once they know what branch they took. This still lets you do the slow memory access before you know if you will need it, without causing globally visible side effects.
    - gpderetta 8y ago
      As soon as you fetch the cache line, every other core will know you have done that via the cache coherency protocol. You have just disclosed an address potentially derived from some sensitive information. Edit: to be precise they can, for example, see the transition from exclusive to shared.
      - gizmo686 8y ago
        I suppose this gets into what is consider a "major" overhaul of the architecture. The idea is that you don't actually "fetch" anything until you are no longer speculating. The core that is doing the speculating can pre-fetch the memory, and then commit it to the cache only once it knows that is the correct thing to do. There are still some cache coherence concerns, but nothing that strikes me as insurmountable.
        gpderetta 8y ago
        I do not understand your distinction between prefect and fetch. You either have the data, and you need to notify other cores that you do or you don't. Not notifying other CPUs seems pointless because before committing you would have to do a round-trip to the other core to verify whether the data is still valid making the prefetching pointless.
        twtw 8y ago
        What you are describing here is high cost, because you have to take care of coherence when the line is committed to the cache, which in your scenario would not be speculative. That would require notifying the other cores and potentially refetching if another core has written to the line between your prefetch and commit. A more practical solution is probably to have protection boundaries within the cache, like http://people.csail.mit.edu/vlk/dawg-micro18.pdf http://people.csail.mit.edu/vlk/dawg-micro18.pdf.
- twtw 8y ago
  Sure, I get it. Perhaps I phrased my response poorly. This comment: > What needs to die is the belief that you can rely on just software (i.e. memory safety) for isolation between trusted and untrusted code is an argument that doubting if statements should be acceptable, and that the assumption that only B has architecturally visible side effects when A is true is not sound. I disagree strongly with that. You should be able to rely on software checks for some things. Going forward, the solution is not to rewrite software to not depend on software mechanisms (e.g. bounds checks) for protection (unclear what would be used instead...) but to fix the hardware so these software mechanisms work. What needs to "die" is not "belief that you can rely on just software," but hardware that violates fundamental guarantees. It sounds like we agree on this, I just wanted to make my point clear since I see now that my original comment was not clear. FWIW, this is essentially the argument Torvalds made when Intel tried to add feature flags for non-broken speculation.
  - gpderetta 8y ago
    I don't think Linus has any expectation that spectre v1 will ever be fixed in hardware.
    - loup-vaillant 8y ago
      There's a difference between what you expect, and how you think things should be. Linus was probably making a normative statement, not a prediction.

by twtw 8y ago

gizmo686 8y ago

The idea behind spectre is that speculative execution bypasses software protections. Given if f(A) B else C, one cannot safely assume that B only gets executed when A resolves to true. It is not reasonable to expect programmers to produce safe code in an environment where they have to doubt if statements. This could be solved without any major overhauls in hardware, by just updating it to make speculative execution actually speculative and not commit any side effects until it knows it went down the correct branch.

gpderetta 8y ago
Unfortunately fetching a new cache line from memory is a globally visible side effect. One of the major benefits of speculation and is that it enables additional memory level parallelism. Even otherwise strictly in order designs, when aiming for high performance incorporate some form of memory speculation (scout threading, run ahead execution).
- gizmo686 8y ago
  Right, and CPUs could, in principle, fix this. Eg. they could speculatively fetch the cache line, and only commit it to the cache once they know what branch they took. This still lets you do the slow memory access before you know if you will need it, without causing globally visible side effects.
  - gpderetta 8y ago
    As soon as you fetch the cache line, every other core will know you have done that via the cache coherency protocol. You have just disclosed an address potentially derived from some sensitive information. Edit: to be precise they can, for example, see the transition from exclusive to shared.
    - gizmo686 8y ago
      I suppose this gets into what is consider a "major" overhaul of the architecture. The idea is that you don't actually "fetch" anything until you are no longer speculating. The core that is doing the speculating can pre-fetch the memory, and then commit it to the cache only once it knows that is the correct thing to do. There are still some cache coherence concerns, but nothing that strikes me as insurmountable.
      - gpderetta 8y ago
        I do not understand your distinction between prefect and fetch. You either have the data, and you need to notify other cores that you do or you don't. Not notifying other CPUs seems pointless because before committing you would have to do a round-trip to the other core to verify whether the data is still valid making the prefetching pointless.
      - twtw 8y ago
        What you are describing here is high cost, because you have to take care of coherence when the line is committed to the cache, which in your scenario would not be speculative. That would require notifying the other cores and potentially refetching if another core has written to the line between your prefetch and commit. A more practical solution is probably to have protection boundaries within the cache, like http://people.csail.mit.edu/vlk/dawg-micro18.pdf http://people.csail.mit.edu/vlk/dawg-micro18.pdf.
twtw 8y ago
Sure, I get it. Perhaps I phrased my response poorly. This comment: > What needs to die is the belief that you can rely on just software (i.e. memory safety) for isolation between trusted and untrusted code is an argument that doubting if statements should be acceptable, and that the assumption that only B has architecturally visible side effects when A is true is not sound. I disagree strongly with that. You should be able to rely on software checks for some things. Going forward, the solution is not to rewrite software to not depend on software mechanisms (e.g. bounds checks) for protection (unclear what would be used instead...) but to fix the hardware so these software mechanisms work. What needs to "die" is not "belief that you can rely on just software," but hardware that violates fundamental guarantees. It sounds like we agree on this, I just wanted to make my point clear since I see now that my original comment was not clear. FWIW, this is essentially the argument Torvalds made when Intel tried to add feature flags for non-broken speculation.
- gpderetta 8y ago
  I don't think Linus has any expectation that spectre v1 will ever be fixed in hardware.
  - loup-vaillant 8y ago
    There's a difference between what you expect, and how you think things should be. Linus was probably making a normative statement, not a prediction.