Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 30 Jan 2018 16:19:14 -0200
From:   Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To:     Borislav Petkov <bp@alien8.de>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        David Woodhouse <dwmw2@infradead.org>, arjan@linux.intel.com,
        karahmed@amazon.de, x86@kernel.org, linux-kernel@vger.kernel.org,
        tim.c.chen@linux.intel.com, peterz@infradead.org,
        pbonzini@redhat.com, ak@linux.intel.com,
        torvalds@linux-foundation.org, gregkh@linux-foundation.org
Subject: Re: [PATCH] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits
 on Intel
Message-ID: <20180130181914.vxheaikugelkfxsb@khazad-dum.debian.net>
References: <1517269773-16750-1-git-send-email-dwmw@amazon.co.uk>
 <20180130105814.m5zd43dyx2o2ius2@pd.tnic>
 <1517310230.18619.86.camel@infradead.org>
 <20180130111848.zjv2dngfzcz35lyt@pd.tnic>
 <1517311693.18619.102.camel@infradead.org>
 <alpine.DEB.2.20.1801301235500.1797@nanos>
 <1517314193.18619.115.camel@infradead.org>
 <alpine.DEB.2.20.1801301349140.1797@nanos>
 <20180130131122.s3bs6lbs43go73gj@pd.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180130131122.s3bs6lbs43go73gj@pd.tnic>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 30 Jan 2018, Borislav Petkov wrote:
> On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote:
> > So much for the theory. That's not going to work. If the boot cpu has the
> > feature then the alternatives will have been applied. So even if the flag
> > mismatch can be observed when a secondary CPU comes up the outcome will be
> > access to a non existing MSR and #GP.
> 
> Yes, with mismatched microcode we're f*cked.
> 
> So my question is: is there such microcode out there or is this
> something theoretical which we want to address?

Old mixed-stepping systems would have mismatched microcode even when
everything went right, just because they had different processor
steppings that took different microcode.

Those systems could have mismatched CPU flags (regardless of their
microcode being up-to-date or not) simply because the processor with the
newer stepping might have more features.  This happened at least once
during the FSB-era Xeons.  I came across several (large three-letter
vendor) x86 Intel-based servers that were in such a condition, *all
using official parts*, because they got upgraded with a second processor
sometime after they were boght, and the part number delivered by said
three-letter vendor was a newer stepping.

You will notice those were all *fully and officially supported* hardware
configurations, and documented as such in the processor specification
updates.

There was also a crop of UEFI and BIOSes out there that would not
properly update the microcode on all processor cores, several years ago.

> And if I were able to wish, I'd like to blacklist that microcode in
> dracut so that it doesn't come anywhere near my system.

Well, the microcode update of a core can soft-fail, and the fact is that
we don't handle such failures at all in any way.  Not that I know what
would be the right error handling for something like this...  kicking
the processor offline (or refusing to online it) might be a good way to
handle it.   And one could at least retry once...  Anyway, we don't even
report it, which is certainly Not Good Enough.

That said, iucode-tool v2.3, released a couple days ago, can do
revision-based blacklisting of microcode[1], if you want to fine-comb
the stuff you're going to ship to your users, etc.


[1] iucode-tool is somewhat widely used *outside* of the Fedora/RedHat
ecosystem, but not even packaged by Fedora, AFAIK.  So, it won't be
relevant to several people in the To/CC list ;-)

-- 
  Henrique Holschuh