linux-kernel - Re: [patch 10/11] [PATCH 10/11] x86: Major refactoring.

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: <488E1FD1.8060902@qualcomm.com>
Date:	Mon, 28 Jul 2008 12:36:49 -0700
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Peter Oruba <peter.oruba@....com>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch 10/11] [PATCH 10/11] x86: Major refactoring.

Peter Oruba wrote:
> Refactored code by introducing a two-module solution. There is one
> general module in which vendor specific modules can hook into.
> However, that is exclusive, there is only one vendor specific module
> allowed at a time. A CPU vendor check makes sure only the corect
> module for the underlying system gets called. Functinally in terms
> of patch loading itself there are no changes. This refactoring
> provides a basis for future implementations of other vendors'
> patch loaders.
> 
> Signed-off-by: Peter Oruba <peter.oruba@....com>
<snip>

> diff --git a/arch/x86/kernel/microcode.c b/arch/x86/kernel/microcode.c
> index c1047d7..1e42e79 100644
> --- a/arch/x86/kernel/microcode.c
> +++ b/arch/x86/kernel/microcode.c
<snip>

> @@ -244,9 +243,9 @@ static void microcode_init_cpu(int cpu, int resume)
>  
>  	set_cpus_allowed_ptr(current, newmask);
>  	mutex_lock(&microcode_mutex);
> -	collect_cpu_info(cpu);
> +	microcode_ops->collect_cpu_info(cpu);
>  	if (uci->valid && system_state == SYSTEM_RUNNING && !resume)
> -		cpu_request_microcode(cpu);
> +		microcode_ops->cpu_request_microcode(cpu);
>  	mutex_unlock(&microcode_mutex);
>  	set_cpus_allowed_ptr(current, &old);
> @@ -274,7 +273,7 @@ static ssize_t reload_store(struct sys_device *dev,
>  
>  		mutex_lock(&microcode_mutex);
>  		if (uci->valid)
> -			err = cpu_request_microcode(cpu);
> +			err = microcode_ops->cpu_request_microcode(cpu);
>  		mutex_unlock(&microcode_mutex);
>  		put_online_cpus();
>  		set_cpus_allowed_ptr(current, &old);

Peter, question while we're at it. This came up in another thread and I 
asked the same question to Tigran but he is either on vacation or not 
paying attention :).

Microcode cpu hotplug handler is messing with the cps_allowed flags of a 
random process and can race with sched_setaffinity() (pointed by 
Dmitry). It also makes some assumptions on the overall cpu hotplug 
sequence which is bad.

It's easy to fix but the question is - does the microcode update need to 
happen synchronously ? I'm thinking that it does not but I wanted to 
verify that. If it does not need to be synchronous then we can simply 
schedule a work queue and do the update there. If it does we could do 
collect_cpu_info() and load_microcode() in the IPIs.

Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/