4 ms·

It saddens me that we're collectively going to spend a lot of effort trying to patch out a problem that we've imposed upon ourselves. We were making such great

It saddens me that we're collectively going to spend a lot of effort trying to patch out a problem that we've imposed upon ourselves. We were making such great progress in terms of processing speed until someone came along and decided that we need to have multiple tenants share the same hardware, and they should have no way of knowing anything about each other. The vast majority of consumer hardware will _never_[0] be exposed to this category of attack, but will pay the performance penalty regardless. Fundamentally, the need is for a completely different model of computation to abstract away time-channel leaks. This cannot be fixed by patching existing software and hardware, and we're going to go through a lot of pain and anguish trying. As another comment points out, the well of possible timing attacks is infinitely deep (attached hardware, network performance measurements, etc.). The two options are performance or security, pick one. It seems the industry is trying to pick both, and it's going to take us a long time to realize that we're going to get neither. For clarity - my proposal is segmenting hardware and software products between the two categories of "general purpose, trusted computing" and "safe for shared hosting." The 2nd category is so small compared to the first, it seems unfair that its domain-specific problems should hamper the rest of us. [0] Thanks to a combination of reasonable software mitigations (unprivileged lower-resolution timers) and that most of these attacks require arbitrary code execution in the first place

speedplane 8y ago
> my proposal is segmenting hardware and software products between the two categories of "general purpose, trusted computing" and "safe for shared hosting." If a normal user is using a web browser and one tab has their bank information, and the other has a suspect website, then you have to be concerned about sharing resources and security.
- gmueckl 8y ago
  Make these web pages run on a crappy VM. Yank most of the JS bloat and the JIT compilers out and you're good. Maybe insert arbitrary nondeterministic delays into the interpreter as well for good measure. Compared to sacrificing total desktop performance, this is a perfect tradeoff.
- xxs 8y ago
  I'd prefer to see 'trusted' sites being to use javascript only. Heck, even use javascript only after log in. Alternatively, run them at an isolated context with no websockets, limited access to timing (second or two precision - a lot sampling needed), limited CPU and memory utilization, no sound, no GPU acceleration [likely another large side channel surface], etc. Ahh yeah and delete all their cookies while we are at. Javascript has turned to a total bloat
  - bo1024 8y ago
    Running somebody else's code is putting a ton of trust in them. Maybe someday we'll have great sandboxing, but for now, it makes no sense to let random sketchy origins to just run whatever code they please on your device.
- Crinus 8y ago
  This is on the browser to handle though and only confined on the browser's process(es), it doesn't need to affect the entire OS.
  - soraminazuki 8y ago
    But things like scheduling and resource sharing do affect the entire OS.
    - Crinus 8y ago
      Yes, so? Unless i'm misunderstanding what you are talking about, these are exposed to (untrusted) web pages through the web browser, the pages do not have a means of accessing it directly. So the browser can take measures of avoiding issues (e.g. decreasing the exposed timing resolution, like browsers now do). Then you can give your (trusted) native applications all the available resources without artificial constraints. (of course this assumes you see most native applications as trusted, but personally i see any alternative as too Orwellian to get behind)
peterkelly 8y ago
> someone came along and decided that we need to have multiple tenants share the same hardware, and they should have no way of knowing anything about each other Isolation between apps on mobile phones is really important. That's a huge part of the computing landscape in terms of number of devices deployed, and falls within the 2nd category. I don't think it's realistic to dismiss so easily.
- gmueckl 8y ago
  Not the GP, but I think this complaint is about workatation and on-premises server performance. There, the software fixes intended for cloud servers are already throwing the baby out with the bathwater for little to no security benefit. All these changes are accomplishing in that space is waste time and energy by ruining hardware performance.
jankotek 8y ago
every phone runs javascript in browser
gnode 8y ago
> The vast majority of consumer hardware will _never_[0] be exposed to this category of attack Arbitrary code execution is common in the browser (Javascript and Webassembly). Really, this is any case where you don't entirely trust every program running on the device (e.g. smartphones). > Thanks to a combination of reasonable software mitigations That is time protection. Restricting access to system timers wasn't enough here; mitigations also need to prevent user-created high resolution timers, so useful features like SharedArrayBuffer had to be disabled, to prevent the creation of synthetic timers. > The two options are performance or security, pick one. That is not the findings of the paper: "Across a set of IPC microbenchmarks, the overhead of time protection is remarkably small on x86 [1%], and within 15% on Arm." I think if there's a segmentation to be made, it's "general purpose, untrusted computing" and "trusted high performance computing". The second category would be the reserve of such projects as physics simulations and render farms.
- chii 8y ago
  > The second category would be the reserve of such projects as physics simulations and render farms. or smoothly scrolling, 60fps rendered canvas apps in browsers. I think there can't be an apartheid between untrusted and trusted, because developers would push the user to make their software trusted to get the max performance (and the users would just agree).
  - gnode 8y ago
    > developers would push the user to make their software trusted I don't see it going this way. This is comparable to virtual memory and MMUs. When there is support in hardware, the speed benefit of not using it is negligible (as shown by the 1% difference demonstrated in the research). When it is not needed, there is a benefit of not implementing it in hardware, and saving power and die area. For example, GPUs (traditionally) and crypto mining hardware do not employ MMUs.

speedplane 8y ago

> my proposal is segmenting hardware and software products between the two categories of "general purpose, trusted computing" and "safe for shared hosting." If a normal user is using a web browser and one tab has their bank information, and the other has a suspect website, then you have to be concerned about sharing resources and security.

gmueckl 8y ago
Make these web pages run on a crappy VM. Yank most of the JS bloat and the JIT compilers out and you're good. Maybe insert arbitrary nondeterministic delays into the interpreter as well for good measure. Compared to sacrificing total desktop performance, this is a perfect tradeoff.
xxs 8y ago
I'd prefer to see 'trusted' sites being to use javascript only. Heck, even use javascript only after log in. Alternatively, run them at an isolated context with no websockets, limited access to timing (second or two precision - a lot sampling needed), limited CPU and memory utilization, no sound, no GPU acceleration [likely another large side channel surface], etc. Ahh yeah and delete all their cookies while we are at. Javascript has turned to a total bloat
- bo1024 8y ago
  Running somebody else's code is putting a ton of trust in them. Maybe someday we'll have great sandboxing, but for now, it makes no sense to let random sketchy origins to just run whatever code they please on your device.
Crinus 8y ago
This is on the browser to handle though and only confined on the browser's process(es), it doesn't need to affect the entire OS.
- soraminazuki 8y ago
  But things like scheduling and resource sharing do affect the entire OS.
  - Crinus 8y ago
    Yes, so? Unless i'm misunderstanding what you are talking about, these are exposed to (untrusted) web pages through the web browser, the pages do not have a means of accessing it directly. So the browser can take measures of avoiding issues (e.g. decreasing the exposed timing resolution, like browsers now do). Then you can give your (trusted) native applications all the available resources without artificial constraints. (of course this assumes you see most native applications as trusted, but personally i see any alternative as too Orwellian to get behind)

peterkelly 8y ago

> someone came along and decided that we need to have multiple tenants share the same hardware, and they should have no way of knowing anything about each other Isolation between apps on mobile phones is really important. That's a huge part of the computing landscape in terms of number of devices deployed, and falls within the 2nd category. I don't think it's realistic to dismiss so easily.

gmueckl 8y ago
Not the GP, but I think this complaint is about workatation and on-premises server performance. There, the software fixes intended for cloud servers are already throwing the baby out with the bathwater for little to no security benefit. All these changes are accomplishing in that space is waste time and energy by ruining hardware performance.

jankotek 8y ago

every phone runs javascript in browser

gnode 8y ago

> The vast majority of consumer hardware will _never_[0] be exposed to this category of attack Arbitrary code execution is common in the browser (Javascript and Webassembly). Really, this is any case where you don't entirely trust every program running on the device (e.g. smartphones). > Thanks to a combination of reasonable software mitigations That is time protection. Restricting access to system timers wasn't enough here; mitigations also need to prevent user-created high resolution timers, so useful features like SharedArrayBuffer had to be disabled, to prevent the creation of synthetic timers. > The two options are performance or security, pick one. That is not the findings of the paper: "Across a set of IPC microbenchmarks, the overhead of time protection is remarkably small on x86 [1%], and within 15% on Arm." I think if there's a segmentation to be made, it's "general purpose, untrusted computing" and "trusted high performance computing". The second category would be the reserve of such projects as physics simulations and render farms.

chii 8y ago
> The second category would be the reserve of such projects as physics simulations and render farms. or smoothly scrolling, 60fps rendered canvas apps in browsers. I think there can't be an apartheid between untrusted and trusted, because developers would push the user to make their software trusted to get the max performance (and the users would just agree).
- gnode 8y ago
  > developers would push the user to make their software trusted I don't see it going this way. This is comparable to virtual memory and MMUs. When there is support in hardware, the speed benefit of not using it is negligible (as shown by the 1% difference demonstrated in the research). When it is not needed, there is a benefit of not implementing it in hardware, and saving power and die area. For example, GPUs (traditionally) and crypto mining hardware do not employ MMUs.