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

[Stanislav Kozina <skozina@redhat.com>]

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