linux-kernel - Re: [PATCH] x86/microcode/intel: print previous microcode revision during early update

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, 07 Feb 2018 15:02:13 +0100
From:   Stanislav Kozina <skozina@...hat.com>
To:     Borislav Petkov <bp@...en8.de>, Petr Oros <poros@...hat.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/microcode/intel: print previous microcode revision
 during early update

Hello Borislav,

On Fri, 2018-01-26 at 15:49 +0100, Borislav Petkov wrote:
> On Fri, Jan 26, 2018 at 02:50:00PM +0100, Petr Oros wrote:
> > But what in production? Edit boot params, restart server, grep
> > /proc/cpuinfo and
> > restart again? Why i can not read it just from dmesg?
> 
> Because you don't need the previous revision.
> 
> You only *happen* to need it now but that is being addressed too with
> the blacklisting. And when you have broken microcode, it will say:

Although Spectre might be the most visible CPU issue, it's not the only
one. What if some issue causes failure during early microcode update?
What if the issue triggers only on update from a certain microcode
version? We should be transparent about what microcode version we
update from and to.

The double reboot with "dis_ucode_ldr" argument requires to schedule a
full system reboot just to figure out what version has been provided by
the system firmware.

> +               pr_warn("Intel Spectre v2 broken microcode detected;
> disabling SPEC_CTRL\n");
> 
> and if you have microcode which doesn't have IBRS, there won't be
> "spec_ctrl" in /proc/cpuinfo.
> 
> I don't want people to start paying attention to microcode
> revision numbers with the gazillion different revisions and
> family/model/steppings out there and the crazy confusion that will
> ensue
> from this.

The current microcode version is already printed in the dmesg. Many
people do care what revision they are running and what provided this
revision. It is the most important information on triaging CPU issues,
especially if anything goes awry.

I would appreciate if you could pull this patch in.

Thank you,
-Stanislav