linux-kernel - Re: [PATCH v2] arch/x86: Fix boot_cpu

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]

Date:   Wed, 1 Aug 2018 17:29:49 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Oleksandr Natalenko <oleksandr@...alenko.name>
Cc:     Prarit Bhargava <prarit@...hat.com>, linux-edac@...r.kernel.org,
        linux-kernel@...r.kernel.org, sironi@...zon.de, tony.luck@...el.com
Subject: Re: [PATCH v2] arch/x86: Fix boot_cpu_data.microcode version output

(drop stable@ from CC)

On Wed, Aug 01, 2018 at 04:16:42PM +0200, Oleksandr Natalenko wrote:
> Once the kernel log does not contain a printout regarding updated microcode
> anymore (because the log buffer is limited in size and can be overwritten)

There's no reliable way to get the old microcode revision which was
overwritten during the upgrade. If dmesg gets overwritten you lose, like
in all the other gazillion cases where you lose information due to that.
Sorry.

This becomes an even bigger problem if you have a long-running system
which upgrades microcode a couple of times before being rebooted again.
In that case, your only log which contains the microcode revisions being
upgraded is dmesg.

> once you have a vmcore, it is handy to use boot_cpu_data to compare
> the microcode version with the per-CPU value to find out that is was
> updated at all.

boot_cpu_data.microcode was never meant to contain the *previous*
microcode revision AFAICT - it just didn't get updated, which we're
fixing now.

> Or, maybe, that can be inspected in another way now?

Dunno, does kdump collect /proc/cpuinfo? If so:

$ grep microcode /proc/cpuinfo

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--