Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <240c8fa4-2872-0584-3cfd-7648ea4dc0eb@citrix.com>
Date: Tue, 8 Aug 2023 19:18:51 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Solar Designer <solar@...nwall.com>,
 "Xen. org security team" <security@....org>
Cc: oss-security@...ts.openwall.com
Subject: Re: Xen Security Advisory 433 v3 (CVE-2023-20593) -
 x86/AMD: Zenbleed

On 08/08/2023 7:00 pm, Solar Designer wrote:
> On Mon, Jul 31, 2023 at 05:00:35PM +0000, Xen. org security team wrote:
>> The patch provided with earlier versions was buggy.  It unintentionally
>> disable more bits than expected in the control register.  The contents of this
>> register is not generally known, so the effects on the system are unknown.
>>
>> A patch correcting this error has been committed and backported to all stable
>> trees which got the XSA-433 fix originally.  Additionally, it is attached to
>> this advisory as xsa433-bugfix.patch, and applicable to all branches in this
>> form.
> where xsa433-bugfix.patch includes this description:
>
>> This line:
>>
>> 	val &= ~chickenbit;
>>
>> ends up truncating val to 32 bits, and turning off various errata workarounds
>> in Zen2 systems.
> and that patch then corrects the truncation by changing the type of the
> chickenbit variable to 64-bit.  The context is:
>
> +	/*
> +	 * Microcode is the preferred mitigation, in terms of performance.
> +	 * However, without microcode, this chickenbit (specific to the Zen2
> +	 * uarch) disables Floating Point Mov-Elimination to mitigate the
> +	 * issue.
> +	 */
> +	val &= ~chickenbit;
> +	if (sig->rev < good_rev)
> +		val |= chickenbit;
>
> This leaves me wondering: why have this line at all?  I understand Xen
> wanting to enable the chicken bit on vulnerable CPUs, but why disable it
> on other AMD CPUs?  If someone or something had enabled the bit, that's
> probably intentional, and even if not it probably shouldn't be Xen's
> business to alter CPU behavior beyond what's necessary for Xen itself to
> work reliably and securely.
>
> Am I missing something?

There is an earlier exit in this function for any non-Zen2 system.

So here, we are strictly on Zen2 (all vulnerable), and either have good
microcode or not.

The microcode fix is far more performant than the chickenbit.

This chickenbit is something unrelated to FP move-elimination on other
microarchitectures.

~Andrew

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.