5 ms·
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
by 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 agoso the perf hit comes from a mandatory cache invalidation instruction added by the patch ?
- DSMan195276 9y agoNo. 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.