[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70e568d7-9e09-a1a9-030f-40473447a619@citrix.com>
Date: Mon, 25 Sep 2023 18:10:05 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Solar Designer <solar@...nwall.com>, oss-security@...ts.openwall.com
Cc: "Xen. org security team" <security-team-members@....org>
Subject: Re: Xen Security Advisory 439 v1 (CVE-2023-20588) -
x86/AMD: Divide speculative information leak
On 25/09/2023 5:36 pm, Solar Designer wrote:
> Hi,
>
> Thank you Xen security team for indirectly bringing the various CPU
> issues in here. This is very helpful, as your messages on them serve
> two purposes at once - informing the community about issues fixed in Xen
> (so directly on-topic here, with Xen being Open Source) and about the
> CPU issues that typically also need to be mitigated by other projects.
>
> On Mon, Sep 25, 2023 at 04:05:37PM +0000, Xen. org security team wrote:
>> Xen Security Advisory CVE-2023-20588 / XSA-439
>>
>> x86/AMD: Divide speculative information leak
>>
>> ISSUE DESCRIPTION
>> =================
>>
>> In the Zen1 microarchitecure, there is one divider in the pipeline which
>> services uops from both threads. In the case of #DE, the latched result
>> from the previous DIV to execute will be forwarded speculatively.
>>
>> This is a covert channel that allows two threads to communicate without
>> any system calls. In also allows userspace to obtain the result of the
>> most recent DIV instruction executed (even speculatively) in the core,
>> which can be from a higher privilege context.
>>
>> For more information, see:
>> * https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html
> The above link is wrong - it's for CVE-2023-20593 Zenbleed in Zen2.
>
> The correct link for CVE-2023-20588, the DIV bug in Zen1, appears to be:
>
> https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7007.html
Oops. I thought I'd fixed that, but apparently not.
You're correct. I'll issue an update in a moment.
>
> While I am at it, here's the corresponding mitigation in Linux kernel:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77245f1c3c6495521f6a3af082696ee2f8ce3921
Not really. That patch entirely misunderstood the vulnerability. I
went through several rounds of getting AMD to better-understand their bug.
Linux's fix was rewritten in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f58d6fbcb7c848b7f2469be339bc571f2e9d245b
and this implements the same logic as I implemented in Xen.
It's worth noting that because AMD did not allocate a $FOO_NO CPUID bit,
there's no ability for a VM to figure out that it might move to
vulnerable hardware and therefore should engage the workaround. The
best a VM can do is best-effort based on whether it looks like it's
booting on a Zen1 system.
Also the cross-thread nature is also poorly reported in public.
Thanks,
~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.
