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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 1 Jan 2014 17:51:59 -0500
From:	Gene Heskett <>
Subject: I'll pay along, if somebody would  tell me the rules


Back on the failure of the amd microcode to properly update the cpu.  It 
seems to be somewhat interlocked with PAE.

Basically, 1. a 64 bit kernel will not boot, I think because it cannot 
access the /boot partition to find its corresponding initrd file.  And if I 
check it, the rest of my .config is mix-mastered, and I have to copy a 
known good .config back into that tree before I can make a PAE kernel that 
actually boots.

2. If I build w/o the PAE, then the microcode update works most of the 

3. With PAE, it hasn't worked since 3.8.2 final.

4. I am building several thousand modules I don't need, because while I can 
turn them off, about 2500-3000 of them but they are found to be back on 
after a build and an attempted boot to that build fails, or doesn't mount 
the /boot partition.  Its a failure either way.

Attached is a .config that builds PAE but the microcode_ctl, when it runs, 
fails.  And if I try to re-run /etc/init.d/microcode_ctl after the boot, I 
get this:

[sudo] password for gene: 
/etc/init.d/microcode_ctl: 90: gprintf: not found

But that is NOT what a demsg|grep microcode says:
gene@...ote:~$ dmesg|grep microcode
microcode: CPU0: patch_level=0x01000065
microcode: CPU1: patch_level=0x01000065
microcode: CPU2: patch_level=0x01000065
microcode: CPU3: patch_level=0x01000065
microcode: Microcode Update Driver: v2.00 <>, 
Peter Oruba

The above snippet should show 4 more lines, indicating the patch_level
is now 0x01000083.

I have been at this for about a week now, even did 3 bisects only to have 
git blame the next makefile at the end of the bisect.  Must be its default 
when it gives up?

Clueless, due to a lack of consistency in expected results, compounded by 
something re-writing my .config file, that much is 100% repeatable.

Clues in the attached .config?  I'll let you tell me if you've the time.

Cheers, Gene

View attachment ".config" of type "text/x-mpsub" (105420 bytes)

Powered by blists - more mailing lists