linux-kernel - Re: [RFC][PATCH 11/17] x86/cpu: Remove all SRSO interface nonsense

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: <64f94037-d370-aa83-f8d8-ae827f606f60@citrix.com>
Date:   Wed, 9 Aug 2023 14:10:42 +0100
From:   Andrew.Cooper3@...rix.com
To:     Peter Zijlstra <peterz@...radead.org>, x86@...nel.org
Cc:     linux-kernel@...r.kernel.org, David.Kaplan@....com,
        jpoimboe@...nel.org, gregkh@...uxfoundation.org,
        Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [RFC][PATCH 11/17] x86/cpu: Remove all SRSO interface nonsense

On 09/08/2023 8:12 am, Peter Zijlstra wrote:
> Now that retbleed can do all that the srso knob did, and without the
> dubious interactions with retbleed selections, remove it.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> ---
>  arch/x86/kernel/cpu/bugs.c |  188 ++-------------------------------------------
>  drivers/base/cpu.c         |    8 -
>  include/linux/cpu.h        |    2 
>  3 files changed, 10 insertions(+), 188 deletions(-)

Not all of this can go, because ...

> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> ...
> -static void __init srso_select_mitigation(void)
> -{
> -	bool has_microcode;
> -
> -	if (!boot_cpu_has_bug(X86_BUG_SRSO) || cpu_mitigations_off())
> -		goto pred_cmd;
> -
> -	/*
> -	 * The first check is for the kernel running as a guest in order
> -	 * for guests to verify whether IBPB is a viable mitigation.
> -	 */
> -	has_microcode = boot_cpu_has(X86_FEATURE_IBPB_BRTYPE) || cpu_has_ibpb_brtype_microcode();
> -	if (!has_microcode) {
> -		pr_warn("IBPB-extending microcode not applied!\n");
> -		pr_warn(SRSO_NOTICE);
> -	} else {
> -		/*
> -		 * Enable the synthetic (even if in a real CPUID leaf)
> -		 * flags for guests.
> -		 */
> -		setup_force_cpu_cap(X86_FEATURE_IBPB_BRTYPE);
> -		setup_force_cpu_cap(X86_FEATURE_SBPB);

... these (minus the virt bug caused by probing for microcode behaviour
even when virtualised, and the enumeration bug caused by ignoring
synthesis if host mitigations are off) are necessary for KVM.

https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf

and here's one I prepared earlier
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=2280b0ee2aed6e0fd4af3fa31bf99bc04d038bfe

but these bits need to get into guests for the guests to be able to
figure out what to do.

~Andrew