Meltdown/Spectre mitigation for 4.15 and beyond [LWN.net]

Meltdown/Spectre mitigation for 4.15 and beyond

Posted Jan 15, 2018 20:29 UTC (Mon) by Otus (subscriber, #67685)
In reply to: Meltdown/Spectre mitigation for 4.15 and beyond by jcm
Parent article: Meltdown/Spectre mitigation for 4.15 and beyond

> turning off the indirect predictor in all of userspace

Is there something in current processors that allows turning off the branch predictor or what does this mean?

to post comments

Meltdown/Spectre mitigation for 4.15 and beyond

Posted Jan 15, 2018 20:41 UTC (Mon) by jcm (subscriber, #18262) [Link] (4 responses)

This (disabling the indirect predictor logic) is what IBRS achieves (restricts indirect branch prediction). But the current patches only do this for entry into the kernel by default. The other half is IBPB, which you can think of as a flush of the predictor state so that when you do a world switch you can flush the state. But there are possible gaps. I'll leave it to the reader to figure them out.

Those IBRS/IBPB interfaces are special MSRs because they're not real MSRs. They're hacks in the microcode to make what look like new MSRs (hence the always-write logic requirement). On other arches, we have more direct control over CPU chicken bits that control indirect predictors and we can whack those directly. But we still have to account for userspace-to-userspace attacks in general. The example from the spectre papers focuses on the latter by way of example anyway.

Meltdown/Spectre mitigation for 4.15 and beyond

Posted Jan 15, 2018 20:49 UTC (Mon) by Otus (subscriber, #67685) [Link]

Ah, so prediction is not disabled, just prevented from interacting between processes?

Meltdown/Spectre mitigation for 4.15 and beyond

Posted Jan 17, 2018 5:29 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

So what does IBRS do exactly (as was also the question in the linux-kernel thread)?

Is it /disabling/ IBP CPU logic? In which case, Andrea Arcangeli's belief that setting it once is sufficient surely must be true?

Or have Intel, with the microcode update, managed to add some bits of context (privilege level, address space?) to the branch-prediction table, and setting this IBRS pseudo-MSR is needed to get the CPU to update its view of the context in some way, so that IBRS must be set on every security relevant context change? Which would be more in-line with David and Arjan's views in that thread?

The lack of documentation and explanation is less than ideal. The security issues are now public. It doesn't make sense to try 'manage' what information is made public about any mitigation features - it can only hamper the speed at which any flaws/issues with those mitigations are uncovered.

Meltdown/Spectre mitigation for 4.15 and beyond

Posted Jan 17, 2018 11:08 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] (1 responses)

Intel documentation is here. I haven't seen public AMD documentation yet (they have IBPB but not IBRS).

No, it isn't just disabling branch prediction completely. I think that what they could achieve in the microcode hacks was fairly limited. So in some ways setting IBRS is a partial barrier, and flushes certain predictions from the store. But leaving IBRS set also makes things go slow, which implies that it's doing some checking at all times. The details are opaque and will vary from generation to generation.

Thankfully we don't really need IBRS except on Skylake (where it doesn't suck quite so much anyway).

Meltdown/Spectre mitigation for 4.15 and beyond

Posted Jan 19, 2018 12:43 UTC (Fri) by anton (subscriber, #25547) [Link]

Unfortunately, the Intel documentation is quite abstract. It does not tell us what these things actually do (probably because that's different for different generations); instead it tries to specify how to use them and/or what guarantees these things give (but even that is not very clear).