linux-kernel - Re: [RFC][PATCH 06/17] x86/cpu: Add SRSO untrain to retbleed=

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: <0ff5cabb-835f-2183-c8a5-5308e23e7f6f@citrix.com>
Date:   Wed, 9 Aug 2023 15:31:20 +0100
From:   Andrew.Cooper3@...rix.com
To:     Josh Poimboeuf <jpoimboe@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, David.Kaplan@....com,
        gregkh@...uxfoundation.org
Subject: Re: [RFC][PATCH 06/17] x86/cpu: Add SRSO untrain to retbleed=

On 09/08/2023 2:42 pm, Josh Poimboeuf wrote:
> On Wed, Aug 09, 2023 at 09:12:24AM +0200, Peter Zijlstra wrote:
>> +	if (boot_cpu_has_bug(X86_BUG_SRSO)) {
>> +		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(RETBLEED_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);
>> +
>> +			/*
>> +			 * Zen1/2 with SMT off aren't vulnerable after the right
>> +			 * IBPB microcode has been applied.
>> +			 */
>> +			if ((boot_cpu_data.x86 < 0x19) &&
>> +			    (cpu_smt_control == CPU_SMT_DISABLED))
>> +				setup_force_cpu_cap(X86_FEATURE_SRSO_NO);
> The rumor I heard was that SMT had to be disabled specifically by BIOS
> for this condition to be true.  Can somebody from AMD confirm?

It's Complicated.

On Zen1/2, uarch constraints mitigate SRSO when the core is in 1T mode,
where such an attack would succeed in 2T mode.  Specifically, it is
believed that the SRSO infinite-call-loop can poison more than 16
RSB/RAS/RAP entries, but can't poison 32 entries.

The RSB dynamically repartitions depending on the idleness of the
sibling.  Therefore, offlining/parking the siblings should make you
safe.  (Assuming you can handwave away the NMI hitting the parked thread
case as outside of an attackers control.)


In Xen, I decided that synthesizing SRSO_NO was only safe when SMT was
disabled by firmware, because that's the only case where it can't cease
being true later by admin action.

If it were just Xen's safety that mattered here it might be ok to allow
the OS SMT=0 cases, but this bit needs to get into guests, you can't
credibly tell the guest SRSO_NO and then make it unsafe at a later point.

~Andrew