linux-kernel - Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Jan 2018 12:34:06 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     David Woodhouse <dwmw2@...radead.org>
cc:     arjan@...ux.intel.com, karahmed@...zon.de, x86@...nel.org,
        linux-kernel@...r.kernel.org, tim.c.chen@...ux.intel.com,
        bp@...en8.de, peterz@...radead.org, pbonzini@...hat.com,
        ak@...ux.intel.com, torvalds@...ux-foundation.org,
        gregkh@...ux-foundation.org, dave.hansen@...el.com,
        gnomes@...rguk.ukuu.org.uk, ashok.raj@...el.com, mingo@...nel.org
Subject: Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early
 Spectre v2 microcodes

On Thu, 25 Jan 2018, David Woodhouse wrote:
> On Thu, 2018-01-25 at 11:54 +0100, Thomas Gleixner wrote:
> > On Thu, 25 Jan 2018, David Woodhouse wrote:
> > > Thomas, want another copy in email now, or were we waiting for another
> > > round of these before you merge them anyway?
> > Looking at this mess makes me even less convinced that a blacklist is a
> > good idea. We have already at least 3 different variants of blacklists.
> > 
> > So I rather see a whitelist approach which says:
> > 
> >    if (ucode_version < known_good(family, model))
> >        return;
> > 
> > I know it would require that Intel releases a set of known good ucodes at
> > some point in the future, but that's a reasonable request.
> > 
> > I rather take a few patches which add the cutoff for family/model (and NO,
> > I don't want to add stepping into the mix at all) than having this
> > blacklist mess which keeps changing every other day.
> 
> I don't know why they added KBL 0x84 microcode; I'm not aware that it's
> been released. Maybe it escaped somewhere so that's why they added it
> to the doc.
> 
> If they ship another bad microcode revision to the public, newer than
> the ones which are already in that list, then there is something
> *SEVERELY* wrong. Wronger than we already know.

Well, all of this is already wrong.

> And if we take this 'piecemeal whitelist' approach, they're going to
> have to add the newly-released microcodes to the kernel each time they
> do a release which covers a new SKU — so it's not like it'll even help,
> because if they *do* ship another bad one, we'll *already* have added
> it to the kernel by the time we realise.

Fair enough.

> I don't expect them to *keep* doing daily releases of the blacklist
> doc; it's just been a bit rushed, that's all. I think we're much better
> off doing it this way than saying that we'll keep taking incremental
> updates as they do new releases.
> 
> Also, I don't think we can avoid looking at the stepping. Not unless
> you want to make Intel synchronise the microcode version numbers for
> different steppings of the same model? Because they aren't at the
> moment.

This stuff is really a master piece of trainwreck engineering.

So yeah, whatever we do we end up with a proper mess. Lets go for a
blacklist and hope that we'll have something which holds at some
foreseeable day in the future.

The other concern I have is IBRS vs. IBPB. Are we sufficiently sure that
IBPB is working on those IBRS blacklisted ucode revisions? Or should we
just play safe and not touch any of this at all when we detect a
blacklisted one?

Given the close to 0 trust in Intels change management and QA, I rather
keep my hands from everything which was ever mentioned in any document as
broken. I hope we have a collection of those PDFs stored at a safe place.

Thanks,

	tglx