linux-kernel - Re: [BUG BISECTED] Phenom microcode revision mis-applied

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: <20131230123700.GS19878@titan.lakedaemon.net>
Date:	Mon, 30 Dec 2013 07:37:00 -0500
From:	Jason Cooper <jason@...edaemon.net>
To:	Gene Heskett <gheskett@...v.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [BUG BISECTED] Phenom microcode revision mis-applied

On Sun, Dec 29, 2013 at 10:02:02PM -0500, Gene Heskett wrote:
...
> Finally done with the forward bisect:
> 
> gene@...ote:~/linux-stable$ dmesg|grep -A2 microcode
> microcode: CPU0: patch_level=0x01000065
> microcode: CPU0: new patch_level=0x01000083
> microcode: CPU1: patch_level=0x01000065
> microcode: CPU1: new patch_level=0x01000083
> microcode: CPU2: patch_level=0x01000065
> microcode: CPU2: new patch_level=0x01000083
> microcode: CPU3: patch_level=0x01000065
> microcode: CPU3: new patch_level=0x01000083
> microcode: Microcode Update Driver: v2.00 <tigran@...azian.fsnet.co.uk>, Peter Oruba
> 
> gene@...ote:~/linux-stable$ git bisect good
> 1a45c310b2102c58e37f84abba67fe21d5d6edcf is the first bad commit
> commit 1a45c310b2102c58e37f84abba67fe21d5d6edcf
> Author: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Date:   Thu Mar 14 11:27:14 2013 -0700
> 
>     Linux 3.8.3
> 
> :100644 100644 20d53183508e8f49253ec7e5ede0a12b4556fc32 8c49fc9b45a993a8e78cde4f9621b727b9121eac M	Makefile
> 
> The v3.8.3 Makefile?  Its just about the only thing that would be bad 
> every step from v3.8.3 to v3.8.2, and good all the way from v3.8.2 to 
> the last patch that made the v3.8.3 release.  Bisected twice, once in
> each direction.

When it works, which CONFIG_MICROCODE* options are set?  And unset when it
fails?

Also, what is the driving problem here?  I know the log entry 'new
patch_level=...' is missing, but what regression are you seeing that is
caused by not updating the microcode?

thx,

Jason.
--
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/