linux-kernel - Re: x86/microcode: intel: correctly handle negative revisions

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] [day] [month] [year] [list]

Message-ID: <4D8C40D0.80109@pbjtriplett.org>
Date:	Fri, 25 Mar 2011 00:14:24 -0700
From:	Burt Triplett <burt@...triplett.org>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
CC:	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: x86/microcode: intel: correctly handle negative revisions

On 3/24/2011 7:09 PM, Henrique de Moraes Holschuh wrote:
> As per the Intel SDM vol 3A, microcode revisions are signed 32-bit
> numbers.  The code was handling them as unsigned int in some places and as
> an int in other places.
> 
> As per the clarification posted by Burt Triplett from the Intel BITS
> project, negative microcode revisions are used internally at Intel and
> should always get loaded.  Also, they should not be overriden unless we
> can somehow differentiate "automated" loading from "forced" loading (which
> we cannot at this time).  Burt says the SDM will be updated with this
> information eventually.
> 
> The code should:
> 
> 1. Ignore attempts to load a zero-revision microcode (that value is
> reserved for the CPU to signal that it is running with the factory
> microcode, and must not be present in a normal microcode update);
> 
> 2. Always load negative revision microcodes, to help Intel's engineers;
> 
> 3. Avoid upgrading from a BIOS-loaded negative revision microcode to
> a normal microcode, to not get in the way of Intel's engineers.
> 
> 4. Upgrade from revision 0 (no updates loaded in CPU) to any revision.
> 
> It was already doing some of that, but I don't feel like trying to track
> down exactly how the old code with its mix of signed/unsigned handling of
> revisions would behave in each of the above cases.
> 
> Signed-off-by: Henrique de Moraes Holschuh <hmh@....eng.br>
> LKML-Reference: <4D87E2CD.6020306@...triplett.org>
> Cc: Tigran Aivazian <tigran@...azian.fsnet.co.uk>
> Cc: "H. Peter Anvin" <hpa@...or.com>
> Cc: Burt Triplett <burt@...triplett.org>

Reviewed-by: Burt Triplett <burt@...triplett.org>

Thanks,
Burt Triplett
--
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/