> Now let's take a step back: you don't really need the previous revision
> in the spectre case! Not really.
I understand all your points.
We submitted the patch to ease debugging of microcode issues where the
systems impacted are not yet identified and thus can't be blacklisted.
Best Regards,
On Wed, Feb 07, 2018 at 03:02:13PM +0100, Stanislav Kozina wrote:
> 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?
And you think failure to update early microcode will allow you to see
*anything* print
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
Borislav Petkov píše v Pá 26. 01. 2018 v 15:49 +0100:
> 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 prev
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
Borislav Petkov píše v Pá 26. 01. 2018 v 12:58 +0100:
> On Fri, Jan 26, 2018 at 12:45:35PM +0100, Petr Oros wrote:
> > During time of facing the Spectre vulnerability and the requirement of
> > handling
> > different microcode updates, it has shown, that it would be useful to have
> > additional i
On Fri, Jan 26, 2018 at 12:45:35PM +0100, Petr Oros wrote:
> During time of facing the Spectre vulnerability and the requirement of
> handling
> different microcode updates, it has shown, that it would be useful to have
> additional information which microcode version was in BIOS, if the
> early-
Borislav Petkov píše v Pá 26. 01. 2018 v 11:41 +0100:
> On Fri, Jan 26, 2018 at 11:34:50AM +0100, Petr Oros wrote:
> > When kernel do early microcode update, code printing only
> > new microcode version. But in this case we no have chance
> > to check which version was in cpu from BIOS vendor
On Fri, Jan 26, 2018 at 11:34:50AM +0100, Petr Oros wrote:
> When kernel do early microcode update, code printing only
> new microcode version. But in this case we no have chance
> to check which version was in cpu from BIOS vendor.
And we need that because?
--
Regards/Gruss,
Boris.
G
When kernel do early microcode update, code printing only
new microcode version. But in this case we no have chance
to check which version was in cpu from BIOS vendor.
Patch add this info into output message.
Signed-off-by: Petr Oros
---
arch/x86/kernel/cpu/microcode/intel.c | 27 ++
10 matches
Mail list logo
