4 ms·

I don't know much about CPUs, so what prevents a fix via microcode update?

• db48x 9y ago
  No one outside of Intel knows enough about Intel's microcode to answer that question, especially since we don't know the full details of the problem.
• dannyw 9y ago
  The bug seems to be revolving around speculative execution. It seems like that is a silicon thing, not a microcode thing.
  • zimmerfrei 9y ago
    The bug seems to be about the processor leaving speculatively read privileged data in some of the caches, even if execution failed [1]. If so, clearing all caches upon a failed privilege check sounds like something within the capabilities of microcode and without unreasonable performance penalties. Unfortunately, that would not explain the complex in-kernel fix... [1] https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoAZxxd https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoA... EDIT: what remains in cache is not "speculatively read privileged data" but more "unprivileged data whose address is correlated to speculatively read privileged data". Retrieving later such address allows one to infer what the privileged data was. Still, the point about clearing all caches as countermeasure holds...
  • rphlx 9y ago
    It's likely they could disable speculative execution in its entirety, either in ucode or UEFI, but that would harm many compute-intensive workloads by 5-10% or more, so my guess is that somebody decided to push this page table mitigation instead, taking the hit on the syscall/hypercall side as that's perceived as "less bad overall".
• fulafel 9y ago
  We don't know if anything does, but it could be that an effective microcode update (eg turning OOO off) would slow down the CPU more than the software fix.