Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes

[David Woodhouse]

On Thu, 2018-01-25 at 17:24 +0100, Thomas Gleixner wrote:
> On Thu, 25 Jan 2018, Alan Cox wrote:
> 
> > 
> > > 
> > > Here's what I have now. I'm happy enough with this, so the main thing
> > > I'm looking for is an ack from Alan for patch #5 of the series, if I've
> > > got that sufficiently correct now.
> > You have my ACK for patch 5: Any further changes I'll submit as updates
> > once it's merged.
> > 
> > I am happy with patch 5 and I think for 64bit we are probably done for
> > the mainstream. VIA/Centaur data would be nice.

Thanks.

> > The microcode otoh I don't think makes sense - do you want to be secure
> > with a slightly higher risk of crashes or insecure ? Once you can point
> > at a newer ucode for each case then yes I personally at least think it
> > then makes sense to tell users they want the newer one.
>
> Yes, ideally we can tell the user to update to ucode rev > X for a
> particular SKU. Though with the current state of affairs all we can do is
> accumulate ucode revisions which are marked bad by Intels Quality
> Assumptions at a given day.

I don't think telling them to upgrade to a specific revision is needed.
If they get a 'bad microcode' message they should update to whatever is
the latest.

As for "slightly higher risk of crashes or insecure"... that's a valid
concern *but* remember we're using retpoline to make the kernel secure,
and we haven't even merged the patches yet which do IBPB on context
switch or IBRS on calling into firmware or any of the other lower-
priority things. I have yet to see a viable proof-of-concept for any of
the holes which remain.

So I think we *can* probably live without the microcode features for
now. In particular I *don't* want to be exposing them to VM guests, so
that VM guests can take the system down by bashing on them.

If you want to add a command-line option to ignore the blacklist and
allow the features to be used, I *suppose* I could tolerate that.
Please make it at least taint the kernel if a bad microcode is actually
used though.

Attachment: smime.p7s
Description: S/MIME cryptographic signature