[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
Date: Mon, 23 Dec 2024 14:24:10 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: "Xen.org security team" <security@....org>, xen-announce@...ts.xen.org,
xen-devel@...ts.xen.org, xen-users@...ts.xen.org,
oss-security@...ts.openwall.com
Cc: "Xen.org security team" <security-team-members@....org>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
page unsafe against speculative attacks
On Tue, 2024-12-17 at 12:18 +0000, Xen.org security team wrote:
> Xen Security Advisory CVE-2024-53241 / XSA-466
> version 3
>
> Xen hypercall page unsafe against speculative attacks
>
> UPDATES IN VERSION 3
> ====================
>
> Update of patch 5, public release.
Can't we even use the hypercall page early in boot? Surely we have to
know whether we're running on an Intel or AMD CPU before we get to the
point where we can enable any of the new control-flow integrity
support? Do we need to jump through those hoops do do that early
detection and setup?
Enabling the hypercall page is also one of the two points where Xen
will 'latch' that the guest is 64-bit, which affects the layout of the
shared_info, vcpu_info and runstate structures.
The other such latching point is when the guest sets
HVM_PARAM_CALLBACK_IRQ, and I *think* that should work in all
implementations of the Xen ABI (including QEMU/KVM and EC2). But would
want to test.
But perhaps it wouldn't hurt for maximal compatibility for Linux to set
the hypercall page *anyway*, even if Linux doesn't then use it — or
only uses it during early boot?
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)
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.
