linux-kernel - Re: [PATCH 1/3] x86: microcode: report if CPU has up-to-date microcode

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: <5339A0F8.70606@redhat.com>
Date:	Mon, 31 Mar 2014 19:08:08 +0200
From:	Denys Vlasenko <dvlasenk@...hat.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Borislav Petkov <bp@...e.de>, Jacob Shin <jacob.shin@....com>,
	Jeff Layton <jlayton@...hat.com>,
	Prarit Bhargava <prarit@...hat.com>,
	Mikulas Patocka <mpatocka@...hat.com>,
	Fenghua Yu <fenghua.yu@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] x86: microcode: report if CPU has up-to-date microcode

On 03/31/2014 06:23 PM, Borislav Petkov wrote:
> On Sun, Mar 30, 2014 at 04:09:32PM +0200, Denys Vlasenko wrote:
>> Before this change, successful microcode uploads clearly
>> indicate that it was done:
>>
>> microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x1a
>> microcode: CPU1 updated to revision 0x29, date = 2013-06-12
>>
>> whereas if microcode was not uploaded, it is not clear why:
>>
>> microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x29
>> (nothing more)
>>
>> So, what was it? No microcode file? No microcode for this sig/pf?
>> CPU already has microcode with this (or newer) revision?
>>
>> In practice, it means that I need to ask people to provide me
>> with more information ("do you have microcode package installed?
>> which version is it?" etc).
> 
> First of all, microcode version is in /proc/cpuinfo.

What prompted me to create this patch is a bunch of vmcores
from people having mysterious crashes.

Basically, I am in a real-world scenario where I have only vmcore
from somebody else. I have no /proc/cpuinfo.

Every bit of information I don't have at a minimum incurs email
round-trip delay.

Eventually I did manage to figure out what version of microcode
my users had (they did have old one), but it took some time.

> Issuing the reason
> why microcode wasn't loaded in dmesg and then the dmesg ring buffer
> wraps around doesn't make a lot of sense, in my not really too humble
> opinion.

You are correct, the lack of boot-time dmesg is a problem for
post-mortem vmcore analysis in general.

I contemplate creating a patch to optionally save it.

> Besides, experience shows that dmesg messages like those tend to spook
> users and we don't want that :-)

That is not a bad thing: if my users would have been spooked that way,
maybe they'd install a newer microcode. Or newer BIOS with new microcode
- they did not do that either, despite it being available
from the manufacturer for two years already.

-- 
vda

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