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

[Ingo Molnar <mingo@kernel.org>]

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

> From: Borislav Petkov <bp@suse.de>
> 
> It is dangerous and it should not be used anyway - there's a nice early
> loading already.
> 
> Requested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Signed-off-by: Borislav Petkov <bp@suse.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