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: <20140331162340.GB16144@pd.tnic>
Date:	Mon, 31 Mar 2014 18:23:40 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Denys Vlasenko <dvlasenk@...hat.com>
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 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).

Well, hmm.

First of all, microcode version is in /proc/cpuinfo. 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.

So, for debugging cases, you're probably going to have to ask for
/proc/cpuinfo anyway and then check the CPU vendor's site for newer
microcode packages and compare, instead of relying that dmesg still
contains that info.

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

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/