linux-kernel - Re: [PATCH 7/8] x86, microcode, intel: forbid some incorrect metadata

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]

Date:	Fri, 8 Aug 2014 10:50:57 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Borislav Petkov <bp@...en8.de>
Cc:	linux-kernel@...r.kernel.org, H Peter Anvin <hpa@...or.com>
Subject: Re: [PATCH 7/8] x86, microcode, intel: forbid some incorrect metadata

On Fri, 08 Aug 2014, Borislav Petkov wrote:
> If someone tries to load a microcode blob which has been split and so
> on, then we should refuse loading. We want to accept microcode from the
> vendor and nothing else glued together.

I don't quite get why we should refuse microcode that has been split by
userspace when the Intel SDM explicitly states that tools can do that if
there is a need, but hey, I consider this to be a very minor point now:

In these last two weeks I tried to look around for microcode loader
implementantions, and now I believe we will *never* see microcode with the
current version of the extended signatures specification.  The loaders in
the field are just too broken, Intel might as well come up with a new and
enhanced design that doesn't have so many sharp edges, since nearly everyone
will have to patch their loaders anyway.

I will respin the patch without the %1024 comment.  Note that I never
*removed* any test, we never tested for %1024 in the first place (nor does
anyone else with the possible exception of proprietary tools to write
microcode to FLASH or merge them into a BIOS image).

> > "CPUID returns a value in a model specific register in addition to its
> > usual register return values. The semantics of CPUID cause it to
> > deposit an update ID value in the 64-bit model-specific register at
> > address 08BH (IA32_BIOS_SIGN_ID).  If no update is present in the
> > processor, the value in the MSR remains unmodified.  The BIOS must
> > pre-load a zero into the MSR before executing CPUID. If a read of the
> > MSR at 8BH still returns zero after executing CPUID, this indicates
> > that no update is present."
> > 
> > Reading a revision of zero really is supposed to mean "no update is
> > present in the processor", and that's because it must be pre-loaded
> > with a zero before cpuid is called.
> > 
> > IMHO, this mean that one should be really paranoid over any Intel
> > microcode update that claims to have a revision of zero.  Intel
> > wouldn't release such a microcode update except in error, and we can
> > safely assume we want nothing to do with any such update attempts.
> 
> Ok, then please change the patch to reflect that - it is not "silicon
> microcode" anymore but revision 0 is special and means no update was
> done. Which is a proper way for the CPU to signal microcode update
> status.

Will change the commit log in the respin.

-- 
  "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/