linux-kernel - Re: [PATCH 7/7] x86/microcode: Recheck IBRS features on microcode reload

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]

Message-ID: <20180105152817.GM26807@redhat.com>
Date:   Fri, 5 Jan 2018 16:28:17 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Borislav Petkov <bp@...en8.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.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 7/7] x86/microcode: Recheck IBRS features on microcode
 reload

Hello everyone,

On Fri, Jan 05, 2018 at 02:32:17PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 04, 2018 at 07:50:33PM +0100, Borislav Petkov wrote:
> > On Thu, Jan 04, 2018 at 07:34:30PM +0100, Andrea Arcangeli wrote:
> > > void spec_ctrl_rescan_cpuid(void)
> > > {
> > > 	int cpu;
> > > 
> > > 	if (use_ibp_disable)
> > > 		return;
> > > 	mutex_lock(&spec_ctrl_mutex);
> > > 	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> > > 	    boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
> > > 		/* detect spec ctrl related cpuid additions */
> > > 		init_scattered_cpuid_features(&boot_cpu_data);
> > 
> > You don't need to noodle through all the scattered features - just the
> > two bits.
> 
> Does it really matter?  Rescanning everything can't hurt here, and it
> shouldn't be noticable in any boot time chart.  I feel like arguing
> about tiny stuff like this takes away from the obvious other problems
> this whole patch series had :(

Yes IMHO it's not worth trying to filter those two bits, sharing the
same function looked much cleaner.

It always helps to get patches to perfection so reviews welcome, but
IMHO the best way forward is to release a kernel with PTI then in rc1
of the next apply ibrs ibpb solution for variant#2 in whatever shape
and form (not necessarily immediately hyper optimized using static key
for the entry code branching or static_cpu_has for once), so that it
activates the microcode IBRS IBPB. Then we can optimize it in rc2 and
later.

About reptoline, I think all reptoline talk it's a waste of time right
now. Reptoline is an attempt to optimize for old CPUs only, it's
hugely more complex to implement and deploy, and for future silicon
it's useless. Even reptoline still requires IBRS and some CPU has no
ibrs so it'd require yet another alternative there and repotline can't
fix skylake anyway, reptoline requires new gcc code that doesn't even
exist today to do a 2-way code emission with 2 different reptolines
for different CPUS with no kernel code that exists that can reconcile
it at boot time to patch it. There's no way to runtime disable it
after applied, and AMD fam 0x10 0x12 0x16 also wouldn't get any
benefit reptoline either, not just skylake wouldn't use it.

Thanks,
Andrea