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  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 <gheskett@...v.com>
To:	linux-kernel@...r.kernel.org
Subject: I'll pay along, if somebody would  tell me the rules

Greetings;

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 
time.

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 <tigran@...azian.fsnet.co.uk>, 
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