linux-kernel - Re: [patch RFC 1/5] x86/CPU: Sync CPU feature flags late

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180110062013.47tbgtccf2wgp5td@gmail.com>
Date:   Wed, 10 Jan 2018 07:20:13 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>, x86@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>,
        Borislav Petkov <bp@...e.de>,
        "Raj, Ashok" <ashok.raj@...el.com>
Subject: Re: [patch RFC 1/5] x86/CPU: Sync CPU feature flags late

* Dave Hansen <dave.hansen@...el.com> wrote:

> On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
> > This is for the case where we need to set feature flags late, like, for
> > example, after late microcode patch has been loaded which has enabled
> > new CPUID bits.
> > 
> > This has no effect on alternatives patching.
> 
> In other words, if you use late microcode loading for getting IBRS, you
> don't get ALTERNATIVE patching and its benefits?
> 
> I'll also profess some microcode ignorance here.  Is "late microcode
> patching" *all* of the stuff we do from the OS, or do we have early and
> late Linux loading in addition to what the BIOS can do?

So would it be really unreasonable to say that if a microcode update changes CPU 
flags an initrd rebuild and a reboot is required? It's not like microcode updates 
are _that_ frequent - in fact they tend to be much _less_ frequent in a system's 
life time than kernel updates.

So all of this 'late loading' and CPU flag splitting complexity seems unnecessary 
to me: we should be glad we do early microcode loading now, and should embrace it.

Changing CPU features way after the CPU has booted up is possible, and we could in 
theory extend code patching to work 'late' as well, but given how infrequent all 
this is bound to be in practice I fear it's all going to be a big, seldom tested, 
often broken mess, with no real benefit to users.

Thanks,

	Ingo