From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <arjan@linux.intel.com>
X-Google-Smtp-Source: AH8x227LH8XJal/QO5Kjj5oOEjB0v2jvkwxyZrM223u7eE6ayymSiN4JQC2tQmA+eZsrph6kbwZW
ARC-Seal: i=1; a=rsa-sha256; t=1517320905; cv=none;
        d=google.com; s=arc-20160816;
        b=b8a1W8m8dDJPUIlO70mjN6dlz/6sEXufK1Pz7K1ynly9GUHHn6iepeg6XMHeiMmXwX
         OigEX8St/xX3AdQXqC4ZgE5XpdMR2oDTitYeMpNV6wfdHUcPjvuwU4ZJmN0qPuxLdlls
         ZBdHflOadI846Q0ezJkjIBQJRuL+UJXGhVVlG+IVCfwDiYBf7TjRvHyJkqnmxyAkHMJd
         vOUkg96wvmQhjPQdna8hCcsWnQ990K2MbaapZkCsJVcz6H2i1RxO5Ja+2OLCkgJChqmp
         /Ku7a9hUAdKGx1pC1uywSbfw1PoE63Y0XQ0v/qRGkKMob6yoKNXlqr1kS/H6hB4uvP+L
         qkDg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:content-language:in-reply-to:mime-version
         :user-agent:date:message-id:from:references:cc:to:subject
         :arc-authentication-results;
        bh=JsuDkVGCWAGQu/e6xOgrrZaiIDccPTYq8yFlK9HX+JI=;
        b=MMzTlpJNDsGfGXr7BX0y8cw+BazAhPP7ZbVEqtah8/vctBaAvlGV5zIb38nWrMonrV
         62CaZP0zu9N5lg0F1Aru1L0HAxktGknztTg2qDqFYtyWxYdXfVBMGcX2UO4pUrANJ19J
         AoaeKh61rGi14Tq1DDlK/XnQm/1bUrLaJz95iFKXP1Ne4adxzuGZwNexuV8zWREnzhKh
         iMjURLuDFArcgbfOEJDgMRIK9gXOVox+i4eChJjISw0tqlDdA4B2MNqb9UYSitR7jEV9
         ausrVPWF3/B4XywhR2T+L3rnCUjV4KFO0FUje1idkyUsLBUOXIk31OebGe9IATczgCIH
         dQ+Q==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: best guess record for domain of arjan@linux.intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=arjan@linux.intel.com
Authentication-Results: mx.google.com;
       spf=pass (google.com: best guess record for domain of arjan@linux.intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=arjan@linux.intel.com
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.46,435,1511856000";
   d="scan'208";a="30619294"
Subject: Re: [PATCH] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits
 on Intel
To: Borislav Petkov <bp@alien8.de>, Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw2@infradead.org>, 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
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>
From: Arjan van de Ven <arjan@linux.intel.com>
Message-ID: <37c4e2a7-6e35-d736-dfaf-83fbe4895401@linux.intel.com>
Date: Tue, 30 Jan 2018 06:01:43 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180130131122.s3bs6lbs43go73gj@pd.tnic>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: =?utf-8?q?1590972687399963990?=
X-GMAIL-MSGID: =?utf-8?q?1591026286006332112?=
X-Mailing-List: linux-kernel@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>

On 1/30/2018 5:11 AM, 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.

I think in the super early days of SMP there was an occasional broken BIOS.
(and when Linux then did the ucode update it was sane again)

Not since a long time though (I think the various certification suites check for it now)

> 
> So my question is: is there such microcode out there or is this
> something theoretical which we want to address?

at this point it's insane theoretical; no OS can actually cope with this, so
if you're an OEM selling this, your customer can run zero OSes ;-)


> 
> (.. and adressing this will be ugly, no matter what.)
> 
> 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.

I'm not sure what you'd want dracut to do... panic() the system
on such a bios?