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] [day] [month] [year] [list]

Message-ID: <20140413160924.GH25088@pd.tnic>
Date:	Sun, 13 Apr 2014 18:09:24 +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 Mon, Mar 31, 2014 at 07:08:08PM +0200, Denys Vlasenko wrote:
> 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.

Out of curiosity: the old microcode version wasn't the culprit for the
bug, was it?

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

Btw, can vmcore stash ucode version somewhere too, as part of the data
dump it saves? Or even the whole /proc/cpuinfo?

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

Right, ok. So in thinking about this more. How about we drop the "bool
report_old" machinery and add those printks as debug printks? And by
that I mean,

	printk(KERN_DEBUG...

and not all that other pr_debug() gunk?

This way, you need to boot with "debug" or "ignore_loglevel" on the
cmdline and they will get issued.

My concern is still with spooked users who'll come and say, my machine says:

+			pr_info("microcode: CPU rev 0x%x is same or newer"
+				" than 0x%x in microcode data\n",

Does that mean, I need to go and replace my CPU?

The usual case is that microcode gets upgraded with system upgrade as a
intel-ucode or amd-ucode or whatever package, so people upgrading their
distros will always get the latest ucode anyway.

Hmmm.

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