linux-kernel - Re: [PATCH 15/23] x86/srso: Remove 'pred

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: <ef77446f-0b9b-ea5e-61b4-da6b747f9892@suse.com>
Date:   Fri, 25 Aug 2023 22:51:04 +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 15/23] x86/srso: Remove 'pred_cmd' label



On 25.08.23 г. 10:01 ч., Josh Poimboeuf wrote:
> SBPB is only enabled in two distinct cases:
> 
> 1) when SRSO has been disabled with srso=off
> 
> 2) when SRSO has been fixed (in future HW)
> 
> Simplify the control flow by getting rid of the 'pred_cmd' label and
> moving the SBPB enablement check to the two corresponding code sites.
> This makes it more clear when exactly SBPB gets enabled.
> 
> Signed-off-by: Josh Poimboeuf <jpoimboe@...nel.org>


I think it never was explained why SBPB should be used when SRSO is 
off/hw is not affected? There's nothing in AMD's whitepape and there's 
nothing in the original patch introducing SRSO_NO. This patch deals with 
the "when", but what about the "Why" ? Can you put this in the changelog 
(if I'm the only one missing this detail)?
> ---
>   arch/x86/kernel/cpu/bugs.c | 21 +++++++++++++--------
>   1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index d883d1c38f7f..3c7f634b6148 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -2410,13 +2410,21 @@ static void __init srso_select_mitigation(void)
>   {
>   	bool has_microcode = boot_cpu_has(X86_FEATURE_IBPB_BRTYPE);
>   
> -	if (!boot_cpu_has_bug(X86_BUG_SRSO) || cpu_mitigations_off())
> -		goto pred_cmd;
> +	if (cpu_mitigations_off())
> +		return;
> +
> +	if (!boot_cpu_has_bug(X86_BUG_SRSO)) {
> +		if (boot_cpu_has(X86_FEATURE_SBPB))
> +			x86_pred_cmd = PRED_CMD_SBPB;
> +		return;
> +	}
>   
>   	if (has_microcode) {
>   		/*
>   		 * Zen1/2 with SMT off aren't vulnerable after the right
>   		 * IBPB microcode has been applied.
> +		 *
> +		 * Zen1/2 don't have SBPB, no need to try to enable it here.
>   		 */
>   		if (boot_cpu_data.x86 < 0x19 && !cpu_smt_possible()) {
>   			setup_force_cpu_cap(X86_FEATURE_SRSO_NO);
> @@ -2439,7 +2447,9 @@ static void __init srso_select_mitigation(void)
>   
>   	switch (srso_cmd) {
>   	case SRSO_CMD_OFF:
> -		goto pred_cmd;
> +		if (boot_cpu_has(X86_FEATURE_SBPB))
> +			x86_pred_cmd = PRED_CMD_SBPB;
> +		return;
>   
>   	case SRSO_CMD_MICROCODE:
>   		if (has_microcode) {
> @@ -2501,11 +2511,6 @@ static void __init srso_select_mitigation(void)
>   
>   out:
>   	pr_info("%s%s\n", srso_strings[srso_mitigation], has_microcode ? "" : ", no microcode");
> -
> -pred_cmd:
> -	if ((!boot_cpu_has_bug(X86_BUG_SRSO) || srso_cmd == SRSO_CMD_OFF) &&
> -	     boot_cpu_has(X86_FEATURE_SBPB))
> -		x86_pred_cmd = PRED_CMD_SBPB;
>   }
>   
>   #undef pr_fmt