Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 25 Sep 2023 18:10:05 +0100
From: Andrew Cooper <>
To: Solar Designer <>,
Cc: "Xen. org security team" <>
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
>> =================
>> 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:
>>  *
> 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:

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:

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
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.



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.