linux-kernel - Re: [PATCH 4/7] x86/idle: Disable IBRS entering idle and enable it on wakeup

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:   Fri, 5 Jan 2018 01:03:11 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Tim Chen <tim.c.chen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/7] x86/idle: Disable IBRS entering idle and enable it
 on wakeup

On Fri, Jan 05, 2018 at 12:45:58AM +0100, Thomas Gleixner wrote:
> What's the problem to make the early update mandatory for this?

That will make a few differences. A host reboot will be required to
use the microcode features, if you upgrade the kernel before the
microcode_ctl package and you won't be able to leverage the new
microcode unless you have an initramfs updated. That's the first time
only so I guess it doesn't matter much. After that if you don't use
initrd/initramfs you won't be able to use the new microcode at all,
just having stuff updated in /lib won't help anymore.

We don't rely on late microcode at all, so it's fine if early
microcode is the only workable option, but in such case it'd look
safer to remove all those different APIs that will be left a bit
bitrotten as they can update microcode but then the kernel can't use
the new microcode feature if the kernel uses static_cpu_has.

Speaking personally I tend to like not to be forced to use initramfs
while testing kernels, so it won't be me converting it to
static_cpu_has and making early microcode mandatory (I went a long way
to make sure late microcode worked in fact), but in production it will
make no difference whatsoever if all late microcode options are not
workable and gone so it's no problem.