From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x2273/pLQXWd9/4JCayl2EHQL6zg/aYNW8OsSvcIqAxp18QhyqbT0s7Vavxy76raWgS53a2eP ARC-Seal: i=1; a=rsa-sha256; t=1517324086; cv=none; d=google.com; s=arc-20160816; b=snVlZa4BROITFGJ/C0VWruQA2dEm+GBnCOPG1iQXafXWcfEixmQwnIKLRBOZFOMP6T tuRgHDOS58/kptCxIWAjVEBEVdUX2RI+lZwa9FBo0q4y+4ROQCgHQk9ZCPyfiXUaJcV0 VP7kLZgCPOQxH38gHrsgJPfeApX9a4SGS295vmbgQ3/nsT2cXzyHupuPkYJ2B1PAroZW wuqNpA4r7pTAJ8noFSF80n6jZ68LFtNDHGLHPtp5VrT0wOGPYKWKlM9NEDStW9acOqct MHdPscaWnIEUfBVgshV2+JvaC4oV751X5TKx8w6lLeseBEDtewx+CViZAqAQwlvHusjS rF+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=6dGlxwEuS/X4jYotFbs8zqy+XKfJydHg1Qbzii+m+Hc=; b=mZJWj7XPnAkD6q5NIF9xvJ/F/hJHCwKVjc7krYNvclQZzhc0zSCcXKRzHj4MxFDT6H Osu+5AVdh0z6Qu7fieTg4iHfIdXcSXyOEhJ3YnnfaxmCUammtsPmX4we9PLUHrUIdk8A gBi0h1PZJZc3MH33swKWJBivz38CctA+VUnWyMkOod4kp/Ni0J5oZ94EkL6oF0lwSlb3 moHQ5Bd4MeZwOIOQ426MC/axurE7UTFj/Wp4FOZJAqdXn8wtNNAvor7S7pAPG7ytLLAd 5bvLPwAhb2BbQo8ztzpuwNyvTLUdpuCn3b6IGDCepnxo7NAEj+NKdV9YKSeO7q4f70sj LZeQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of gnomes@lxorguk.ukuu.org.uk designates 82.70.14.225 as permitted sender) smtp.mailfrom=gnomes@lxorguk.ukuu.org.uk Authentication-Results: mx.google.com; spf=pass (google.com: domain of gnomes@lxorguk.ukuu.org.uk designates 82.70.14.225 as permitted sender) smtp.mailfrom=gnomes@lxorguk.ukuu.org.uk Date: Tue, 30 Jan 2018 14:54:17 +0000 From: Alan Cox To: Arjan van de Ven Cc: Borislav Petkov , Thomas Gleixner , David Woodhouse , 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: <20180130145417.71b0c859@alans-desktop> In-Reply-To: <37c4e2a7-6e35-d736-dfaf-83fbe4895401@linux.intel.com> 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> <1517314193.18619.115.camel@infradead.org> <20180130131122.s3bs6lbs43go73gj@pd.tnic> <37c4e2a7-6e35-d736-dfaf-83fbe4895401@linux.intel.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590972687399963990?= X-GMAIL-MSGID: =?utf-8?q?1591029621196519202?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Tue, 30 Jan 2018 06:01:43 -0800 Arjan van de Ven wrote: > 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) The only case I can think of where you'd get a non boot processor that didn't have the same microcode loaded as the rest on entry to the OS would be in a system where it was possibly to phyically hot plug processors post boot. There are not many such systems and it may be that all of them do sufficient deeply unmentionable things in their firmware to cover this. Alan