linux-kernel - Re: [PATCH 02/22] x86/srso: Set CPUID feature bits independently of bug or mitigation status

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: <35c7815e-4212-2c14-1515-bd10e9e649db@suse.com>
Date:   Mon, 21 Aug 2023 08:42:08 +0300
From:   Nikolay Borisov <nik.borisov@...e.com>
To:     Josh Poimboeuf <jpoimboe@...nel.org>, x86@...nel.org
Cc:     linux-kernel@...r.kernel.org, Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Babu Moger <babu.moger@....com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>, David.Kaplan@....com,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        gregkh@...uxfoundation.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 02/22] x86/srso: Set CPUID feature bits independently of
 bug or mitigation status



On 21.08.23 г. 4:18 ч., Josh Poimboeuf wrote:
> Booting with mitigations=off incorrectly prevents the
> X86_FEATURE_{IBPB_BRTYPE,SBPB} CPUID bits from getting set.
> 
> Also, future CPUs without X86_BUG_SRSO might still have IBPB with branch
> type prediction flushing, in which case SBPB should be used instead of
> IBPB.  The current code doesn't allow for that.
> 
> Also, cpu_has_ibpb_brtype_microcode() has some surprising side effects
> and the setting of these feature bits really doesn't belong in the
> mitigation code anyway.  Move it to earlier.
> 
> Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
> Signed-off-by: Josh Poimboeuf <jpoimboe@...nel.org>

LGTM and it's a lot more clear when IBPB_TYPE can actually be set.

Reviewed-by: Nikolay Borisov <nik.borisov@...e.com>


> ---
>   arch/x86/include/asm/processor.h |  2 --
>   arch/x86/kernel/cpu/amd.c        | 28 +++++++++-------------------
>   arch/x86/kernel/cpu/bugs.c       | 13 +------------
>   3 files changed, 10 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index fd750247ca89..9e26294e415c 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -676,12 +676,10 @@ extern u16 get_llc_id(unsigned int cpu);
>   #ifdef CONFIG_CPU_SUP_AMD
>   extern u32 amd_get_nodes_per_socket(void);
>   extern u32 amd_get_highest_perf(void);
> -extern bool cpu_has_ibpb_brtype_microcode(void);
>   extern void amd_clear_divider(void);
>   #else
>   static inline u32 amd_get_nodes_per_socket(void)	{ return 0; }
>   static inline u32 amd_get_highest_perf(void)		{ return 0; }
> -static inline bool cpu_has_ibpb_brtype_microcode(void)	{ return false; }
>   static inline void amd_clear_divider(void)		{ }
>   #endif
>   
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 7eca6a8abbb1..b08af929135d 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -766,6 +766,15 @@ static void early_init_amd(struct cpuinfo_x86 *c)
>   
>   	if (cpu_has(c, X86_FEATURE_TOPOEXT))
>   		smp_num_siblings = ((cpuid_ebx(0x8000001e) >> 8) & 0xff) + 1;
> +
> +	if (!cpu_has(c, X86_FEATURE_IBPB_BRTYPE)) {

The only way this check can be true is if this kernel is running as a 
guest and KVM has synthesized this flag already, right?

> +		if (c->x86 == 0x17 && boot_cpu_has(X86_FEATURE_AMD_IBPB))
> +			setup_force_cpu_cap(X86_FEATURE_IBPB_BRTYPE);
> +		else if (c->x86 >= 0x19 && !wrmsrl_safe(MSR_IA32_PRED_CMD, PRED_CMD_SBPB)) {
> +			setup_force_cpu_cap(X86_FEATURE_IBPB_BRTYPE);
> +			setup_force_cpu_cap(X86_FEATURE_SBPB);
> +		}
> +	}
>   }
>   
>   static void init_amd_k8(struct cpuinfo_x86 *c)

<snip>