4 ms·

This is a good middle ground, but ... ... leakage by timing side-channels depends in parts on how accurate your time-measurements are (e.g. Javascript's timer

This is a good middle ground, but ... ... leakage by timing side-channels depends in parts on how accurate your time-measurements are (e.g. Javascript's timer resolution was degraded, in order to make transient failure attacks like Spectre harder [1]). I totally agree with your second point and believe, but cannot prove, that no current processor with any competitive performance is free from timing side-channels, the best we can currently do is put upper bounds on leakage rate. There are just so many other timing side channels, e.g. port contention [2]. They just keep popping up ... Another dimension is the very meaning of thread. Presumably, as an end-user, you care about the threads/processes that the operating systems defines. But they don't map one-to-one to hardware threads, cores etc. Indeed I would argue that processors don't have threads in the sense that end-users care about. So the relevant security property must be regarding a hardware/software interface. Quite how to nail down this isolation property is active research I think. See e.g. [3] for work from 2016 in this direction. Yet another dimension to this is through passwords and similar mechanisms: presumably you want to allow doing things like "sudo" so a low-priority thread can increase priority, provided the former knows the right password. But the very act of supplying a false password, leaks a tiny bit of information (that can be quantified in terms of Shannon-style information theory) about the password's search space. [1] https://hackaday.com/2018/01/06/lowering-javascript-timer-resolution-thwarts-meltdown-and-spectre/ https://hackaday.com/2018/01/06/lowering-javascript-timer-re... [2] A. Bhattacharyya, A. Sandulescu, M. Neugschwandtner, A. Sorniotti, B. Falsafi, M. Payer, A. Kurmus, SMoTherSpectre: Exploiting Speculative Execution through Port Contention. https://arxiv.org/abs/1903.01843 https://arxiv.org/abs/1903.01843 [3] D. Costanzo, Z. Shao, R. Gu, End-to-end verification of information flow security for C and assembly programs. https://6826.csail.mit.edu/2019/papers/certikos-sec.pdf https://6826.csail.mit.edu/2019/papers/certikos-sec.pdf

londons_explore 6y ago
I'd like to see CPU's having a notion of "theoretical time" and "real time". Theoretical time ticks once per CPU instruction or similar. Real time is kept in sync with theoretical time by slowing the CPU down if theoretical time gets ahead, and throwing an exception if real time gets ahead. All IO with untrusted devices would be delayed until the real time exceeds the theoretical time the message was sent. Then one can have as many timing sidechannels as one likes, and the running program can never learn about them.
- GregarianChild 6y ago
  That would be great. But isn't there a danger, that such a CPU, at least if implemented naievely, would basically mostly idle, since modern OoO processors schedule memory access dynamically? For hard real-time tasks, some CPUs don't have caches, to make timing more predictable, but there is a heavy performance penalty to be paid for that predictability. Are you familiar with works like [1]? That is thinking in this direction, but from a different angle. [1] G. Heiser, G. Klein, T. Murray, Can We Prove Time Protection?. https://arxiv.org/pdf/1901.08338.pdf https://arxiv.org/pdf/1901.08338.pdf
  - sitkack 6y ago
    > heavy performance penalty to be paid for that predictability I think this is probably a fascinating area of study. It feels like there is a power/time/space non-linearity and being able to trade one for another. How about the CPU is put into a fixed timestep mode, where all operations take the same amount of time. If there was a hardware level concept of a thread, it could be a thread property. Another option would be a queue of futures with a rate control based on the required security properties.
fuklief 6y ago
> ... leakage by timing side-channels depends in parts on how accurate your time-measurements are (e.g. Javascript's timer resolution was degraded, in order to make transient failure attacks like Spectre harder [1]). But that doesn't matter if how long it takes for your instructions to execute is data independent, no ?
- GregarianChild 6y ago
  How are you planning to ensure that all victim code has data-independent timing?
a1369209993 6y ago
> ... leakage by timing side-channels depends in parts on how accurate your time-measurements are The rate of leakage from a existing timing side-channel depends on how accurate your time-measurements are; the presence of such a side channel does not. (Though one shouldn't discount the value of degrading a side channel from kilobytes per second to millibits per hour, even the latter will only protect a reasonably-sized private key for a decade or two.)

londons_explore 6y ago

I'd like to see CPU's having a notion of "theoretical time" and "real time". Theoretical time ticks once per CPU instruction or similar. Real time is kept in sync with theoretical time by slowing the CPU down if theoretical time gets ahead, and throwing an exception if real time gets ahead. All IO with untrusted devices would be delayed until the real time exceeds the theoretical time the message was sent. Then one can have as many timing sidechannels as one likes, and the running program can never learn about them.

GregarianChild 6y ago
That would be great. But isn't there a danger, that such a CPU, at least if implemented naievely, would basically mostly idle, since modern OoO processors schedule memory access dynamically? For hard real-time tasks, some CPUs don't have caches, to make timing more predictable, but there is a heavy performance penalty to be paid for that predictability. Are you familiar with works like [1]? That is thinking in this direction, but from a different angle. [1] G. Heiser, G. Klein, T. Murray, Can We Prove Time Protection?. https://arxiv.org/pdf/1901.08338.pdf https://arxiv.org/pdf/1901.08338.pdf
- sitkack 6y ago
  > heavy performance penalty to be paid for that predictability I think this is probably a fascinating area of study. It feels like there is a power/time/space non-linearity and being able to trade one for another. How about the CPU is put into a fixed timestep mode, where all operations take the same amount of time. If there was a hardware level concept of a thread, it could be a thread property. Another option would be a queue of futures with a rate control based on the required security properties.

fuklief 6y ago

> ... leakage by timing side-channels depends in parts on how accurate your time-measurements are (e.g. Javascript's timer resolution was degraded, in order to make transient failure attacks like Spectre harder [1]). But that doesn't matter if how long it takes for your instructions to execute is data independent, no ?

GregarianChild 6y ago
How are you planning to ensure that all victim code has data-independent timing?

a1369209993 6y ago

> ... leakage by timing side-channels depends in parts on how accurate your time-measurements are The rate of leakage from a existing timing side-channel depends on how accurate your time-measurements are; the presence of such a side channel does not. (Though one shouldn't discount the value of degrading a side channel from kilobytes per second to millibits per hour, even the latter will only protect a reasonably-sized private key for a decade or two.)