4 ms·

The only way we can actually stop timing-based side channel attacks is by having deterministic (in time) execution. The only way that can happen is by running a

The only way we can actually stop timing-based side channel attacks is by having deterministic (in time) execution. The only way that can happen is by running at the slowest hypothetical rate for every individual operation. So, no cache, dedicated CPU timeslices, dedicated RAM bandwidth. Luckily, we only need this for untrusted code. What really peaves me is that trusted code is now having to run slower as well.

wffurr 5y ago
With supply chain attacks, all code is untrusted.
- andrewinardeer 5y ago
  Unless you mine your own silicon all hardware is untrusted.
  - FredPret 5y ago
    Only if you write every bit of code and trust every person involved in the entire value chain
    - kirubakaran 5y ago
      But even then, do you trust yourself?
      - FredPret 5y ago
        Right, what if you’ve been Inception-ed by an adversary
      - FranchuFranchu 5y ago
        Maybe the NSA installed a backdoor in your brain.
- ant6n 5y ago
  With JavaScript in Browsers, every consumer pc runs untrusted code every day.
  - patrickthebold 5y ago
    I don't think it's so black and white. When I install some software I'm trusting the developer and the package maintainer, and I'm sure others. If I go to gmail, I'm trusting google. That's not a huge difference at the end of the day. I suppose it's easier to navigate around to lots of websites than it is to go an install a bunch of software. But then again, browser exploits have been a thing forever. I expect that something bad will happen to my computer if I'm visiting shady websites. So my question is: are shady websites _more_ dangerous now that these side channel attacks have been discovered? (serious question.)
    - remram 5y ago
      You're trusting Google to do what? Google is not trying to attack you, but they are using a different threat model than what you describe. In particular Google is in the business of serving ads to you, that they do not author themselves, and are written with the assumption that you are not blindly running all their code ring0.
  - acdha 5y ago
    But they do so in a highly-sandboxed environment which has constantly evolving mitigations to counter exactly this threat.
- tgb 5y ago
  Sure, but you don't need to mitigate timing attacks on untrusted code if that code already has root access.
- hedora 5y ago
  You mean it’s untrustworthy code. Supply chain attacks exploit that fact that far too much code is inappropriately trusted.
wongarsu 5y ago
Allowing the CPU to drop into a deterministic-performance mode would be quite useful not only for running untrusted code (whatever we decide to be "untrusted"), but also for cryptography. So many classes of side channel attacks would simply vanish, or at least become controllable.
jandrese 5y ago
I wish there was a flag you could set on a CPU that would switch it between "fast" and "safe" modes. Security conscious stuff could switch it into safe mode and then it could be switched back to fast mode for general computation. I don't like that everything has to get 25% slower because your SSL session setup needs to be protected.
ytpete 5y ago
> Luckily, we only need this for untrusted code. What really peaves me is that trusted code is now having to run slower as well. Realistically though, most userland software falls into that category nowadays: - JS-driven web apps like GSuite - Sandboxed "App Store" apps on mobile and even desktop - Potentially any other desktop app that is exposed to content originating from the web or email (e.g. Acrobat, desktop Office, etc.) I wonder if security models need to become less black-and-white, with a middle tier of trust for apps or domain names that should still be sandboxed but are trusted enough that we're willing to trade some risk of timing exploits for improved performance?

wffurr 5y ago

With supply chain attacks, all code is untrusted.

andrewinardeer 5y ago
Unless you mine your own silicon all hardware is untrusted.
- FredPret 5y ago
  Only if you write every bit of code and trust every person involved in the entire value chain
  - kirubakaran 5y ago
    But even then, do you trust yourself?
    - FredPret 5y ago
      Right, what if you’ve been Inception-ed by an adversary
    - FranchuFranchu 5y ago
      Maybe the NSA installed a backdoor in your brain.
ant6n 5y ago
With JavaScript in Browsers, every consumer pc runs untrusted code every day.
- patrickthebold 5y ago
  I don't think it's so black and white. When I install some software I'm trusting the developer and the package maintainer, and I'm sure others. If I go to gmail, I'm trusting google. That's not a huge difference at the end of the day. I suppose it's easier to navigate around to lots of websites than it is to go an install a bunch of software. But then again, browser exploits have been a thing forever. I expect that something bad will happen to my computer if I'm visiting shady websites. So my question is: are shady websites _more_ dangerous now that these side channel attacks have been discovered? (serious question.)
  - remram 5y ago
    You're trusting Google to do what? Google is not trying to attack you, but they are using a different threat model than what you describe. In particular Google is in the business of serving ads to you, that they do not author themselves, and are written with the assumption that you are not blindly running all their code ring0.
- acdha 5y ago
  But they do so in a highly-sandboxed environment which has constantly evolving mitigations to counter exactly this threat.
tgb 5y ago
Sure, but you don't need to mitigate timing attacks on untrusted code if that code already has root access.
hedora 5y ago
You mean it’s untrustworthy code. Supply chain attacks exploit that fact that far too much code is inappropriately trusted.

wongarsu 5y ago

Allowing the CPU to drop into a deterministic-performance mode would be quite useful not only for running untrusted code (whatever we decide to be "untrusted"), but also for cryptography. So many classes of side channel attacks would simply vanish, or at least become controllable.

jandrese 5y ago

I wish there was a flag you could set on a CPU that would switch it between "fast" and "safe" modes. Security conscious stuff could switch it into safe mode and then it could be switched back to fast mode for general computation. I don't like that everything has to get 25% slower because your SSL session setup needs to be protected.

ytpete 5y ago

> Luckily, we only need this for untrusted code. What really peaves me is that trusted code is now having to run slower as well. Realistically though, most userland software falls into that category nowadays: - JS-driven web apps like GSuite - Sandboxed "App Store" apps on mobile and even desktop - Potentially any other desktop app that is exposed to content originating from the web or email (e.g. Acrobat, desktop Office, etc.) I wonder if security models need to become less black-and-white, with a middle tier of trust for apps or domain names that should still be sandboxed but are trusted enough that we're willing to trade some risk of timing exploits for improved performance?