Re: Xen Security Advisory 439 v1 (CVE-2023-20588) - x86/AMD: Divide speculative information leak

[Andrew Cooper <andrew.cooper3 () citrix com>]

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