I am aware that there is no microcode fix for Meltdown available (it has already been answered in various questions), and that the only extant microcode patches (IBRS and IPBP) only help with one of the Spectre variants, but I would like to know if a microcode fix for Meltdown is possible and feasible.

Specifically, I am curious whether or not:

  • Intel's microcode implementation is sufficiently capable to mitigate Meltdown.
  • Such a mitigation would be possible without an extreme performance hit.
  • A microcode fix is practical enough that, in the future, one may be released.
  • There is simply not enough public information to answer this question.

I already know that KPTI is the current "official" fix for Meltdown and that microcode and that new compiler instrumentation partially deal with Spectre. Disclaimer: I have not watched the 34c3 talk which may shed light on the limitations of Intel microcode, but I am aware that it has limitations.

  • It is hard to say what aspects of a cpu can be influenced with the Microcode. However asuming that the parts which need to change are not implemented in hardware it might be possible to not only offer new instructions but also alter the caching and cache invalidation on changes to the priveledge level. But it would most likely be slow.
    – eckes
    Jan 18, 2018 at 23:10
  • @eckes Why would it need to be slow? I would imagine that there are low-level configuration options (lower than that which can be toggled via MSRs) which microcode can affect. I don't think it would require microcode patching of every instruction which touches memory. After all, IBRS and IPBP are not that slow, and those touch the behavior of cache invalidation across privilege boundaries.
    – forest
    Jan 20, 2018 at 11:51
  • It probably could be implemented in a way that it can analyse the context and be save and fast, however since Intel does not do it it means it is complicated or exceeds the capabilities of the simple instructions and internal data models. The only magic thing it seems is to stop crosstalk between multiple threads with the STIPB control. But I guess even that affects performance.
    – eckes
    Jan 24, 2018 at 8:19

1 Answer 1


I've seen a satisfactory answer on an LWN thread. Taken from a comment made by jcm:

I doubt it’s possible in microcode. Let’s look at it:

  1. Speculative loads. Only thing you could do in microcode is turn off all speculation, or maybe cause every load to be serializing (similar).

  2. Branch prediction. You could turn off the indirect predictors (but that’s what IBRS does).*

  3. Permission checking during speculation. You can either turn off speculation or the cache, or kill the TLBs or you’re pretty much out of options.

You can’t just replace random instructions in microcode, or add complex behavior, for several reasons:

  1. Not every instruction is microcoded. Fast path instructions don’t even touch the microcode sequencer.

  2. The patch RAM for the microcode is tiny and can’t carry anything like that kind of patch.

  3. Complex TLB and branch predictor logic isn’t under direct algorithmic control via microcode, only certain aspects of it are. You can alter behavior, tweak chicken bits, play with control signals...but you can’t add what isn’t already in the design.

Microcode isn’t magic. It’s there to fix mostly run of the mill complex instructions that don’t behave correctly, or to whack chicken bits, and so on.

* This statement regarding IBRS behavior was disputed in another comment on LWN.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .