linux-kernel - Re: [RFC PATCH 2/3] x86/microcode: Default-disable late loading

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: <YpCp5B7noKAt+91A@gmail.com>
Date:   Fri, 27 May 2022 12:37:24 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH 2/3] x86/microcode: Default-disable late loading


* Borislav Petkov <bp@...en8.de> wrote:

> From: Borislav Petkov <bp@...e.de>
> 
> It is dangerous and it should not be used anyway - there's a nice early
> loading already.
> 
> Requested-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> Signed-off-by: Borislav Petkov <bp@...e.de>
> ---
>  arch/x86/Kconfig                     | 11 +++++++++++
>  arch/x86/kernel/cpu/common.c         |  2 ++
>  arch/x86/kernel/cpu/microcode/core.c |  7 ++++++-
>  3 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 1c0da2dbfb26..33891b82fb65 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1345,6 +1345,17 @@ config MICROCODE_AMD
>  	  If you select this option, microcode patch loading support for AMD
>  	  processors will be enabled.
>  
> +config MICROCODE_LATE_LOADING
> +	bool "Late microcode loading (DANGEROUS)"
> +	default n
> +	depends on MICROCODE
> +	help

( Small nit: 'default n' is the default, there's no need to list it 
  explicitly - and that's the convention as well. )

> +	  Loading microcode late, when the system is up and executing instructions
> +	  is a tricky business and should be avoided if possible. Just the sequence
> +	  of synchronizing all cores and SMT threads is one fragile dance which does
> +	  not guarantee that cores might not softlock after the loading. Therefore,
> +	  use this at your own risk. Late loading taints the kernel too.

Might make sense to outline here valid circumstances under which late 
loading is used? Such as some weird kernel package that doesn't have the 
latest firmware included in the initrd?

Because it's hard (for me) to see any valid circumstance under which late 
loading should be supported at all TBH: new kernels where this patch is 
active would come with a modern package.

Ie. we should consider removing late loading altogether.

Thanks,

	Ingo