linux-kernel - Re: [PATCH 1/3] x86, intel: Output microcode revision

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110525160656.GB25225@khazad-dum.debian.net>
Date:	Wed, 25 May 2011 13:06:56 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH 1/3] x86, intel: Output microcode revision

On Wed, 25 May 2011, Ingo Molnar wrote:
> * Andi Kleen <andi@...stfloor.org> wrote:
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -111,6 +111,8 @@ struct cpuinfo_x86 {
> >  	/* Index into per_cpu list: */
> >  	u16			cpu_index;
> >  #endif
> > +	/* CPU update signature */
> > +	u32			x86_cpu_update;
> 
> Btw,. there's one subtle thing here: it's possible to have *different* 
> microcode versions on different CPUs in te system.
> 
> This can happen if for example the BIOS somehow does not apply the right 
> microcode to all CPUs. It can also happen if physically different microcode 
> version CPUs are mixed. In theory people can mix steppings as well.

In PRACTICE people WILL mix steppings as well.

I have some boxes like that, here.  It is especifically supported by
server vendors, BIOS vendors, and also by Intel.  And it happens easily
when people decide to add processors to a non-maxed-out box a few years
after it has been acquired.

Heck, I am pretty sure at least one of those boxes with mismatched
steppings we have here was SOLD to us by IBM Brazil already with
mismatched steppings installed.

So, please consider this a field report that mixed CPU steppings in X86
SMP boxes are somewhat common.

> been brought online, and print some very visible boot warning message if 
> there's a mismatch between the steppings or microcode versions? Perhaps also 
> taint the kernel.

Mismatched microcode within processors with the same processor
identification (the full one, as used by the microcode matching logic)
would be something to *fix* in the first place (we should be updating CPU
microcode before we bring the CPU online anyway) and it would be nice to
warn if we don't have the suitable microcode and the BIOS screwed it up,
indeed...

But mismatched stepping?  We cannot taint or warn on mismatched stepping,
it is an explicitly supported configuration by the hardware and firmware
vendors.

BTW, microcode versions, at least for Intel, do not match across different
steppings (i.e. different processor signatures).  They do not always match
even across CPUs with the same processor signature but different processor
flags!   In fact, it is RARE when they do match.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/