3 ms·

From my cursory reading I understand it is a cleverly orchestrated timing attack. In other words, if something would need 500 picoseconds you have bit 1, if it

From my cursory reading I understand it is a cleverly orchestrated timing attack. In other words, if something would need 500 picoseconds you have bit 1, if it is 250 picoseconds instead it is bit 0 (numbers pulled out of thin air). This is made possible because processors execute the read speculatively even if it is actually forbidden. This read causes a cache hit. Of course the read is never brought into effect because first it is forbidden and second it is in a branch which will never be executed. At the time of the speculative read the CPU seems not to have enough information to know not to execute that read. Even speculatively. And that speculative read has a side effect on the cache which is measured by the exploit. Of course the read is never made visible to the process because later the CPU knows not to bring it into effect. However then it is too late: there is measurable difference in caching times. Did I understand the way of the attack correctly?

JdeBP 9y ago
Timing the L1 cache response for speculatively fetched data that one could not normally access is just one of the problems. It's the one that it is easiest to explain, and it's also the one that the few operating system writers who were told about this tackled first. Hence it is the one that is getting the focus in many discussions. * https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/ https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne... (https://news.ycombinator.com/item?id=16080002 https://news.ycombinator.com/item?id=16080002) * https://dev.to/isaacandsuch/how-meltdown-works-28j2 https://dev.to/isaacandsuch/how-meltdown-works-28j2 (https://news.ycombinator.com/item?id=16085592 https://news.ycombinator.com/item?id=16085592) One of the other problems is tricking the branch predictor into speculatively jumping into code of one's choosing. * https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf https://newsroom.intel.com/wp-content/uploads/sites/11/2018/... (https://news.ycombinator.com/item?id=16079910 https://news.ycombinator.com/item?id=16079910)
- jancsika 9y ago
  > One of the other problems is tricking the branch predictor into speculatively jumping into code of one's choosing. But to read the data one still must use timing attacks, no?
DSMan195276 9y ago
Yes, you understand it correctly. The bug is really just that cache hits that are caused by speculative execution do not get invalidated. This is technically a bit of a speed-up, but it leaves information behind about the speculative execution that took place. It is also worth understanding the differences between Spectre and Meltdown, since they are distinct. Spectre refers to reading process memory via measuring cache timing after speculative execution. Meltdown, in conjunction, refers to the fact that Intel CPUs do not verify access rights to a virtual address until after the speculative execution (and thus the cache hit) takes place. Meltdown allows bypassing page permissions so you can read any page mapped in your virtual address space. Spectre is 'limited' to only reading addresses you already have access too.
- agumonkey 9y ago
  so the perf hit comes from a mandatory cache invalidation instruction added by the patch ?
  - DSMan195276 9y ago
    No. That would be the ideal situation, but it is not possible to make the CPU do that just from a microcode update, it would require new hardware. So we're left with creating other ways to get around it via software. The perf hit comes from those software fixes. Meltdown is the most expensive perf wise, but more straight forward to fix. Processes can only access addresses mapped in their address space, so if you in unmap the kernel while a user process is running then they can't read it. This is expensive because every syscall now flushes the TLB due to changing the page table, so page accesses are in general slower. Spectre is more complicated to fix. One part of the fix is the retpoline hack that basically attempts to defeat the branch predictor through clever code. It looks like the CPUs are also getting microcode update to allow it to disable the branch predictor in some situations.

JdeBP 9y ago

Timing the L1 cache response for speculatively fetched data that one could not normally access is just one of the problems. It's the one that it is easiest to explain, and it's also the one that the few operating system writers who were told about this tackled first. Hence it is the one that is getting the focus in many discussions. * https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/ https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne... (https://news.ycombinator.com/item?id=16080002 https://news.ycombinator.com/item?id=16080002) * https://dev.to/isaacandsuch/how-meltdown-works-28j2 https://dev.to/isaacandsuch/how-meltdown-works-28j2 (https://news.ycombinator.com/item?id=16085592 https://news.ycombinator.com/item?id=16085592) One of the other problems is tricking the branch predictor into speculatively jumping into code of one's choosing. * https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf https://newsroom.intel.com/wp-content/uploads/sites/11/2018/... (https://news.ycombinator.com/item?id=16079910 https://news.ycombinator.com/item?id=16079910)

jancsika 9y ago
> One of the other problems is tricking the branch predictor into speculatively jumping into code of one's choosing. But to read the data one still must use timing attacks, no?

DSMan195276 9y ago

Yes, you understand it correctly. The bug is really just that cache hits that are caused by speculative execution do not get invalidated. This is technically a bit of a speed-up, but it leaves information behind about the speculative execution that took place. It is also worth understanding the differences between Spectre and Meltdown, since they are distinct. Spectre refers to reading process memory via measuring cache timing after speculative execution. Meltdown, in conjunction, refers to the fact that Intel CPUs do not verify access rights to a virtual address until after the speculative execution (and thus the cache hit) takes place. Meltdown allows bypassing page permissions so you can read any page mapped in your virtual address space. Spectre is 'limited' to only reading addresses you already have access too.

agumonkey 9y ago
so the perf hit comes from a mandatory cache invalidation instruction added by the patch ?
- DSMan195276 9y ago
  No. That would be the ideal situation, but it is not possible to make the CPU do that just from a microcode update, it would require new hardware. So we're left with creating other ways to get around it via software. The perf hit comes from those software fixes. Meltdown is the most expensive perf wise, but more straight forward to fix. Processes can only access addresses mapped in their address space, so if you in unmap the kernel while a user process is running then they can't read it. This is expensive because every syscall now flushes the TLB due to changing the page table, so page accesses are in general slower. Spectre is more complicated to fix. One part of the fix is the retpoline hack that basically attempts to defeat the branch predictor through clever code. It looks like the CPUs are also getting microcode update to allow it to disable the branch predictor in some situations.