linux-kernel - Re: [PATCH] x86/boot: Delay BSP init until after FPU initialization

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]

Date:   Sun, 20 Sep 2020 10:36:26 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Mike Hommey <mh@...ndium.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/boot: Delay BSP init until after FPU initialization

On Sun, Sep 20, 2020 at 10:03:10AM +0900, Mike Hommey wrote:
> FPU initialization handles the clearcpuid command line argument. If it
> comes after BSP init, clearcpuid cannot be used to disable features that
> trigger some parts of the BSP init code.
> 
> Signed-off-by: Mike Hommey <mh@...ndium.org>
> ---
>  arch/x86/kernel/cpu/common.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> I was trying to use clearcpuid=440 to disable X86_FEATURES_AMD_SSBD to
> reproduce the behavior that happens on Zen/Zen+ on a Zen2 machine, but
> that didn't work because the command line is handled after the setup for
> X86_FEATURE_LS_CFG_SSBD.
> 
> I tought about either moving the command line handling earlier, but it
> seems there wasn't a specific reason for BSP init being earlier than FPU
> initialization so I went with reordering those instead.

Our boot order is fragile and the functionality in
fpu__init_parse_early_param() which does the clearcpuid= parsing should be
independent from FPU, as your use case shows.

So I'd prefer if you moved that function perhaps to right after the call

  setup_force_cpu_cap(X86_FEATURE_CPUID);

in early_identify_cpu() and renamed it to something generic instead.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette