linux-kernel - Re: [PATCH 7/7] x86/microcode: Synchronize late microcode loading

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, 28 Feb 2018 15:08:06 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:     X86 ML <x86@...nel.org>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/7] x86/microcode: Synchronize late microcode loading

On Wed, Feb 28, 2018 at 10:59:31AM -0300, Henrique de Moraes Holschuh wrote:
> Eek! If I read that right, this effectively halts the entire box until
> every core is updated, with one core entering deep-coma at a time (the
> rest are left either spinning or cpu_relax()ing

I think *you* should relax. :)

Late microcode loading on a long running box is not something you do
more than 2-3 times a year. And if the box needs to restart, it'll get
the early microcode.

And yes, this is addressing *late* loading, if you haven't noticed yet.
I added a big fat note *twice*:

"Before you read any further: the early loading method is still the
preferred one and you should always do that. This patchset is improving
the late loading mechanism for long running jobs and cloud use cases -
i.e., use cases where early loading is, hm, a bit problematic."

So keep doing the early method and you'll be fine.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.