4 ms·

I'm a bit reluctant to reply without having looked at the article in detail, but I feel confident that the answer must be negative! Why? Because the very conc

I'm a bit reluctant to reply without having looked at the article in detail, but I feel confident that the answer must be negative! Why? Because the very concept of side-channel depends on attacker capability! For example, does your attacker have physical access to the processor or not? With physical access you can exploit channels like power consumption through differential power analysis, or shoot laser pulses at target transistors to flip them and induce the processor to leak secrets. OTOH, without physical access, those channels don't meaningfully exist and you need to rely on, for example, speculation failure attacks and exfiltration via cache timing. So what counts as a side-channel is attacker-capability dependent.

londons_explore 6y ago
A good middle ground is to say "no secret data should be leaked via timing of operations". Ie. a high security and a low security thread on the same CPU should not be able to get clues about what data the other has in its address space. Offering stricter protection than that is pretty hard - simply the fact that one thread is using the floating point units a lot and causing the CPU to throttle is an info leak, so I don't think it's possible to really prevent small leaks of flow control information.
- GregarianChild 6y ago
  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 ?
- jpaul23 6y ago
  I think most of practical timing attacks are on software pieces rather than hardware, if two threads interact using some way (pipes, IPC, TCP) you can't blame the CPU for the inter-threads leaks, looks for example how a simple RSA timing attack works, it depends on software implementation. Of course you can use branch-less code to avoid timing leak at some point, but some leaks depend on the algorithm.
  - GregarianChild 6y ago
    Yes, so you want to say something like: the CPU doesn't allow additional timing attacks that already exist in software. Making such a relational property formal in a way that is usable in practise is a hard problem.
- a1369209993 6y ago
  I agree that that's good level of security to ask for, but it's a vastly less vague level of security than "verified for side-channel attacks".

londons_explore 6y ago

A good middle ground is to say "no secret data should be leaked via timing of operations". Ie. a high security and a low security thread on the same CPU should not be able to get clues about what data the other has in its address space. Offering stricter protection than that is pretty hard - simply the fact that one thread is using the floating point units a lot and causing the CPU to throttle is an info leak, so I don't think it's possible to really prevent small leaks of flow control information.

GregarianChild 6y ago
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 ?
jpaul23 6y ago
I think most of practical timing attacks are on software pieces rather than hardware, if two threads interact using some way (pipes, IPC, TCP) you can't blame the CPU for the inter-threads leaks, looks for example how a simple RSA timing attack works, it depends on software implementation. Of course you can use branch-less code to avoid timing leak at some point, but some leaks depend on the algorithm.
- GregarianChild 6y ago
  Yes, so you want to say something like: the CPU doesn't allow additional timing attacks that already exist in software. Making such a relational property formal in a way that is usable in practise is a hard problem.
a1369209993 6y ago
I agree that that's good level of security to ask for, but it's a vastly less vague level of security than "verified for side-channel attacks".