Page MenuHomeFreeBSD

Spectre AKA IBRS
ClosedPublic

Authored by kib on Jan 24 2018, 2:35 PM.

Details

Summary

Coded according to the 336996-001.

Test Plan

Tested on Haswell with recalled microcode.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kib created this revision.Jan 24 2018, 2:35 PM
emaste added inline comments.Jan 24 2018, 4:16 PM
sys/amd64/amd64/initcpu.c
67 ↗(On Diff #38388)

Probably avoiding negative-sense tunables/sysctls is preferred (although we have clfush_disable just above, perhaps maintaining consistency is sensible)

swills added a subscriber: swills.Jan 24 2018, 4:26 PM
op added a subscriber: op.Jan 24 2018, 8:47 PM
op requested changes to this revision.Jan 24 2018, 9:39 PM
op added inline comments.
sys/amd64/amd64/support.S
831 ↗(On Diff #38388)

According to 2.5.1.3 the CPUID_STDEXT3_IBPD is not IA32_ARCH_CAP_IBRS_ALL?

This revision now requires changes to proceed.Jan 24 2018, 9:39 PM
op resigned from this revision.Jan 24 2018, 9:41 PM

Nevermind, it's handled.

op added inline comments.Jan 24 2018, 9:57 PM
sys/amd64/amd64/support.S
828 ↗(On Diff #38388)

1f

2.5.1.3:
~~~
On processors with enhanced IBRS, an RSB overwrite sequence does not suffice to prevent the
predicted target of a near return from using an RSB entry created in a less privileged predictor mode.
Software can avoid this by enabling SMEP (for transitions from user mode to supervisor mode
) and by maintaining IA32_SPEC_CTRL.IBRS = 1 (for VM exits).
~~~

op added inline comments.Jan 24 2018, 10:20 PM
sys/amd64/amd64/support.S
831 ↗(On Diff #38388)

Nope, it's fine, just the CPUID_STDEXT3_IBPD was named misleading.

kib added inline comments.Jan 25 2018, 3:08 PM
sys/amd64/amd64/support.S
828 ↗(On Diff #38388)

Re-read the citation and the code where you put the note. Your suggestion would result in doing something which is exactly opposite to what is recommended in the 2.5.1.3. If the IA32_ARCH_CAP_IBRS_ALL bit is set, then RSB reset sequence is useless, while jmp 1f would jump right to the sequence. Instead, the paragraph recommends to enable SMEP as the measure.

We always have SMEP turned on if CPU supports it, there is no such action as turning SMEP on after the kernel is booted. So there is nothing to do in the case of enhanced IBRS.

kib updated this revision to Diff 38533.Jan 27 2018, 6:07 PM
  • Disable IBPB on return to usermode
  • Ensure that IBPB is enabled on kernel entry before we enable interrupts. Then we do not need to tweak MSRs when re-entering kernel.
  • Except for NMI and MCE, where we preserve previous MSR content on entry and restore on exit, to ensure proper nesting.
  • Disable IBPB around mwait, Intel claims that if any HT has the control enabled, it hurts the whole core performance.
imp added a comment.Jan 27 2018, 6:14 PM

Would it make sense to reference Intel doc 336996-001 somewhere in a comment?

kib added a comment.Jan 27 2018, 6:30 PM
In D14029#295586, @imp wrote:

Would it make sense to reference Intel doc 336996-001 somewhere in a comment?

If this interface is to stay, Intel must move the content of the whitepaper into SDM. I will add a note to specialregs.h for now.

kib updated this revision to Diff 38717.Jan 31 2018, 11:45 AM

Pre-calculate all IBRS pre-conditions instead of doing it on each kernel entry.
Disable IBRS on return if it was enabled, regardless of the IBRS enable state.

I'm curious: why disable IBPB for userland?

This revision was not accepted when it landed; it landed in state Needs Review.Jan 31 2018, 2:36 PM
This revision was automatically updated to reflect the committed changes.