linux-kernel - RE: [PATCH 1/2] x86, microcode: Sanitize per-cpu microcode reloading interface

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-next>] [day] [month] [year] [list]

Message-ID: <3E5A0FA7E9CA944F9D5414FEC6C712200773763E@ORSMSX105.amr.corp.intel.com>
Date:	Tue, 19 Jun 2012 23:15:56 +0000
From:	"Yu, Fenghua" <fenghua.yu@...el.com>
To:	X86-ML <x86@...nel.org>
CC:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Borislav Petkov <borislav.petkov@....com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Peter Zijlstra <peterz@...radead.org>
Subject: RE: [PATCH 1/2] x86, microcode: Sanitize per-cpu microcode
 reloading interface

> From: Borislav Petkov <bp@...64.org>
> Date: Tue, 19 Jun 2012 18:03:30 +0200
> Subject: [PATCH 1/2] x86, microcode: Sanitize per-cpu microcode
> reloading interface
> To: X86-ML <x86@...nel.org>
> Cc: "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
> Thomas Gleixner <tglx@...utronix.de>, LKML
> <linux-kernel@...r.kernel.org>, Andreas Herrmann
> <andreas.herrmann3@....com>, Borislav Petkov
> <borislav.petkov@....com>, Henrique de Moraes Holschuh
> <hmh@....eng.br>, Peter Zijlstra <peterz@...radead.org>,
> stable@...r.kernel.org
> 
> From: Borislav Petkov <borislav.petkov@....com>
> 
> Microcode reloading in a per-core manner is a very bad idea for both
> major x86 vendors. And the thing is, we have such interface with which
> we can end up with different microcode versions applied on different
> cores of an otherwise homogeneous wrt (family,model,stepping) system.
> 
> So turn off the possibility of doing that per core and allow it only
> system-wide.
> 
> This is a minimal fix which we'd like to see in stable too thus the
> more-or-less arbitrary decision to allow system-wide reloading only on
> the BSP:
> 
> $ echo 1 > /sys/devices/system/cpu/cpu0/microcode/reload
> ...
> 
> and disable the interface on the other cores:
> 
> $ echo 1 > /sys/devices/system/cpu/cpu23/microcode/reload
> -bash: echo: write error: Invalid argument
> 
> Also, allowing the reload only from one CPU (the BSP in
> that case) doesn't allow the reload procedure to degenerate
> into an O(n^2) deal when triggering reloads from all
> /sys/devices/system/cpu/cpuX/microcode/reload sysfs nodes
> simultaneously.
> 
> A more generic fix will follow.
> 
> Cc: Henrique de Moraes Holschuh <hmh@....eng.br>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: stable@...r.kernel.org
> Signed-off-by: Borislav Petkov <borislav.petkov@....com>
> ---
>  arch/x86/kernel/microcode_core.c | 26 +++++++++++++++++++-------
>  1 file changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kernel/microcode_core.c
> b/arch/x86/kernel/microcode_core.c
> index fbdfc6917180..24b852b61be3 100644
> --- a/arch/x86/kernel/microcode_core.c
> +++ b/arch/x86/kernel/microcode_core.c
> @@ -298,19 +298,31 @@ static ssize_t reload_store(struct device *dev,
>  			    const char *buf, size_t size)
>  {
>  	unsigned long val;
> -	int cpu = dev->id;
> -	ssize_t ret = 0;
> +	int cpu;
> +	ssize_t ret = 0, tmp_ret;
> +
> +	/* allow reload only from the BSP */
> +	if (boot_cpu_data.cpu_index != dev->id)
> +		return -EINVAL;

With the /sys/devices/system/cpu/microcode/reload interface in your patch 2/2, this will be broken, right? With the new interface, reload_store() can be executed on any cpu or dev. I think you need to remove this check if working with the patch 2/2.

Thanks.

-Fenghua
--
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/