7 ms·

I don't understand this at all; I didn't think the mico-op cache was visible to code written for the x86 ISA at all. Can anyone explain to an idiot (me) how s

I don't understand this at all; I didn't think the mico-op cache was visible to code written for the x86 ISA at all. Can anyone explain to an idiot (me) how something in micro-op cache can become visible to the outside world?

tux3 5y ago
I'm simplifying a bit (edit: quite a bit =]), but the way these attacks work is generally by exploiting the difference in timing between something being in cache, and something not being in cache. Or some resource being contended vs not contended. If something is in cache, and you also have access to that cache, accessing that thing will be fast and few CPU resources will be used. So you can tell that something is in cache. And you know you didn't put it there. So some other thread that you're sharing a CPU core with must have put it there. To exploit those attacks, you're going to intentionally watch the other thread as it, for example, (speculatively) takes a branch, and either puts something in cache or doesn't. Now you know whether the other thread (speculatively) took a branch or not! Just from measuring timings of the cache. From that, you work back to what the branch condition (that was still only speculatively executed) must have been, and if this branch is based on (speculatively loaded) data, you just leaked one or more bits of the data. Suddenly, things are not speculative anymore. You guessed data that wasn't yours, because speculatively using it had an effect on the cache, and you could measure that effect. Here, they use the micro-op cache (I haven't read the paper, so I don't know the details, but this is broad strokes). Any mechanism that you can use during speculation, and that you can extract timing information from is potentially a problem. And these are everywhere. That's why the Spectre problem is so hard to fix now that pandora's box is open.
- fnord77 5y ago
  so something say, sandboxed (like in a browser running webassembly) could get at non-sandboxed data? Or something in one VM getting at data from a different VM?
  - DoomHotel 5y ago
    There are examples of straight JavaScript exploits that allow a website to read memory from anywhere in the process its code is running in. https://cacm.acm.org/magazines/2020/7/245682-spectre-attacks/fulltext https://cacm.acm.org/magazines/2020/7/245682-spectre-attacks...
- mikewarot 5y ago
  The fix is simple, don't allow access to clocks or timing information in anything other than the microkernel that runs the OS.
  - jeffbee 5y ago
    That would break so many things.
    - mikewarot 5y ago
      Proper multi-level security doesn't allow access to the clock in anything other than the top level. You could just have a monotonically counter that is periodically synced to reality every minute or two.
      - jeffbee 5y ago
        I must be misunderstanding what you are suggesting, since what it seems like you are suggesting would never work. High-resolution timing information is available to user applications via numerous APIs today. Hyrum's Law, and common sense, tell us we can't just lose this feature of operating systems and expect applications to work.
      - titzer 5y ago
        You can construct a high resolution timer from shared mutable memory and multiple threads. It's simple. One thread increments a counter, and the other thread reads it.
  - xucheng 5y ago
    You don't need OS to build a very precise clock for the purpose of exploiting timing attack. That's why SharedArrayBuffer[1] is disabled in all browsers. Moreover, not every side channel attack relies on timing attack. For interested readers, there is a paper titled "Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript", which discussed a variety of ways to build high resolution clocks. [1]: https://security.stackexchange.com/questions/177033/how-can-sharedarraybuffer-be-used-for-timing-attacks https://security.stackexchange.com/questions/177033/how-can-...
nabla9 5y ago
There is no direct access. These exploits use a side channel attacks. They feed the CPU code where the execution reveals information indirectly.

tux3 5y ago

I'm simplifying a bit (edit: quite a bit =]), but the way these attacks work is generally by exploiting the difference in timing between something being in cache, and something not being in cache. Or some resource being contended vs not contended. If something is in cache, and you also have access to that cache, accessing that thing will be fast and few CPU resources will be used. So you can tell that something is in cache. And you know you didn't put it there. So some other thread that you're sharing a CPU core with must have put it there. To exploit those attacks, you're going to intentionally watch the other thread as it, for example, (speculatively) takes a branch, and either puts something in cache or doesn't. Now you know whether the other thread (speculatively) took a branch or not! Just from measuring timings of the cache. From that, you work back to what the branch condition (that was still only speculatively executed) must have been, and if this branch is based on (speculatively loaded) data, you just leaked one or more bits of the data. Suddenly, things are not speculative anymore. You guessed data that wasn't yours, because speculatively using it had an effect on the cache, and you could measure that effect. Here, they use the micro-op cache (I haven't read the paper, so I don't know the details, but this is broad strokes). Any mechanism that you can use during speculation, and that you can extract timing information from is potentially a problem. And these are everywhere. That's why the Spectre problem is so hard to fix now that pandora's box is open.

fnord77 5y ago
so something say, sandboxed (like in a browser running webassembly) could get at non-sandboxed data? Or something in one VM getting at data from a different VM?
- DoomHotel 5y ago
  There are examples of straight JavaScript exploits that allow a website to read memory from anywhere in the process its code is running in. https://cacm.acm.org/magazines/2020/7/245682-spectre-attacks/fulltext https://cacm.acm.org/magazines/2020/7/245682-spectre-attacks...
mikewarot 5y ago
The fix is simple, don't allow access to clocks or timing information in anything other than the microkernel that runs the OS.
- jeffbee 5y ago
  That would break so many things.
  - mikewarot 5y ago
    Proper multi-level security doesn't allow access to the clock in anything other than the top level. You could just have a monotonically counter that is periodically synced to reality every minute or two.
    - jeffbee 5y ago
      I must be misunderstanding what you are suggesting, since what it seems like you are suggesting would never work. High-resolution timing information is available to user applications via numerous APIs today. Hyrum's Law, and common sense, tell us we can't just lose this feature of operating systems and expect applications to work.
    - titzer 5y ago
      You can construct a high resolution timer from shared mutable memory and multiple threads. It's simple. One thread increments a counter, and the other thread reads it.
- xucheng 5y ago
  You don't need OS to build a very precise clock for the purpose of exploiting timing attack. That's why SharedArrayBuffer[1] is disabled in all browsers. Moreover, not every side channel attack relies on timing attack. For interested readers, there is a paper titled "Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript", which discussed a variety of ways to build high resolution clocks. [1]: https://security.stackexchange.com/questions/177033/how-can-sharedarraybuffer-be-used-for-timing-attacks https://security.stackexchange.com/questions/177033/how-can-...

nabla9 5y ago

There is no direct access. These exploits use a side channel attacks. They feed the CPU code where the execution reveals information indirectly.