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: <20180104183430.GJ13348@redhat.com>
Date:   Thu, 4 Jan 2018 19:34:30 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Tim Chen <tim.c.chen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        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 7/7] x86/microcode: Recheck IBRS features on microcode
 reload

On Thu, Jan 04, 2018 at 07:28:58PM +0100, Borislav Petkov wrote:
> On Thu, Jan 04, 2018 at 09:56:48AM -0800, Tim Chen wrote:
> > On new microcode write, check whether IBRS
> > is present by rescanning scattered CPU features.
> > 
> > Signed-off-by: Tim Chen <tim.c.chen@...ux.intel.com>
> > ---
> >  arch/x86/kernel/cpu/microcode/core.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
> > index c4fa4a8..44b9355 100644
> > --- a/arch/x86/kernel/cpu/microcode/core.c
> > +++ b/arch/x86/kernel/cpu/microcode/core.c
> > @@ -40,6 +40,7 @@
> >  #include <asm/processor.h>
> >  #include <asm/cmdline.h>
> >  #include <asm/setup.h>
> > +#include <asm/spec_ctrl.h>
> >  
> >  #define DRIVER_VERSION	"2.2"
> >  
> > @@ -444,6 +445,11 @@ static ssize_t microcode_write(struct file *file, const char __user *buf,
> >  	if (ret > 0)
> >  		perf_check_microcode();
> >  
> > +	/* check spec_ctrl capabilities */
> > +	mutex_lock(&spec_ctrl_mutex);
> > +	init_scattered_cpuid_features(&boot_cpu_data);
> 
> No need for that - make a specific function like perf_check_microcode()
> which checks only the IBRS bit and updates stuff accordingly.

It would be better I agree. I've got this:

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);
		spec_ctrl_init(&boot_cpu_data);

		/*
		 * The SPEC_CTRL and IBPB_SUPPORT cpuid bits may have
		 * just been set in the boot_cpu_data, transfer them
		 * to the per-cpu data too. This must run after
		 * spec_ctrl_init() to take care of
		 * setup_force_cpu_cap() too.
		 */
		if (cpu_has_spec_ctrl())
			for_each_online_cpu(cpu)
				set_cpu_cap(&cpu_data(cpu),
					    X86_FEATURE_SPEC_CTRL);
		if (boot_cpu_has(X86_FEATURE_IBPB_SUPPORT))
			for_each_online_cpu(cpu)
				set_cpu_cap(&cpu_data(cpu),
					    X86_FEATURE_IBPB_SUPPORT);
	}
	mutex_unlock(&spec_ctrl_mutex);
}

However we've to start somewhere so that is a simpler start..