On Mon, 2018-02-12 at 12:50 +0100, Peter Zijlstra wrote:
> On Mon, Feb 12, 2018 at 11:22:11AM +0100, Ingo Molnar wrote:
> > > +static inline void firmware_restrict_branch_speculation_start(void)
> > > +{
> > > + alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,
> > > + X86_FEATURE_USE_IBRS_FW);
> > > +}
> > > +
> > > +static inline void firmware_restrict_branch_speculation_end(void)
> > > +{
> > > + alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,
> > > + X86_FEATURE_USE_IBRS_FW);
> >
> > BTW., there's a detail that only occurred to me today, this enabling/disabling
> > sequence is not NMI safe, and it might be called from NMI context:
>
> Wait, we're doing firmware from NMI? That sounds like a _REALLY_ bad
> idea.
And spin_lock_irqsave() too. Which is probably why I missed the fact
that this was being called in NMI context.
Yay for HP and their persistent attempts to "value subtract" in their
firmware offerings.
I'm tempted to drop that part of the patch and declare that if you're
using this driver, the potential for stray branch prediction when you
call into the firmware from the NMI handler is the *least* of your
problems.
I *will* go back over the other parts of the patch and audit them for
preempt safety though; there could potentially be a similar issue
there. I think I put them close enough to the actual firmware calls
that if we aren't already preempt-safe then we were screwed anyway, but
*maybe* there's merit in making the macros explicitly bump the preempt
count anyway.Attachment:
smime.p7s
Description: S/MIME cryptographic signature
|