Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall page unsafe against speculative attacks

[Jürgen Groß <jgross@xxxxxxxx>]

On 02.01.25 13:53, David Woodhouse wrote:
> On Thu, 2025-01-02 at 13:07 +0100, Jürgen Groß wrote:
> > On 23.12.24 15:24, David Woodhouse wrote:
> > > 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?
> > The downside of this approach would be to have another variant to do
> > hypercalls. So you'd have to replace the variant being able to use AMD
> > or INTEL specific instructions with a function doing the hypercall via
> > the hypercall page.
> You'd probably start with the hypercall function just jumping directly
> into the temporary hypercall page during early boot, and then you'd
> update them to use the natively prepared vmcall/vmmcall version later.
>
> All the complexity of patching and CPU detection in early boot seems to
> be somewhat gratuitous and even counter-productive given the change it
> introduces to 64-bit latching.
>
> And even if the 64-bit latch does happen when HVM_PARAM_CALLBACK_IRQ is
> set, isn't that potentially a lot later in boot? Xen will be treating
> this guest as 32-bit until then, so won't all the vcpu_info and
> runstate structures be wrong even as the secondary CPUs are already up
> and running?
What I don't get is why this latching isn't done when the shared info
page is mapped into the guest via the XENMAPSPACE_shared_info hypercall
or maybe additionally when VCPUOP_register_runstate_memory_area is being
used by the guest.

These are the earliest possible cases where the guest is able to access
this data.

> > I'm planning to send patches for Xen and the kernel to add CPUID feature
> > bits indicating which instruction to use. This will make life much easier.
> >
> > > 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?
> > I'm seeing potential problems with that approach when someone is using
> > an out-of-tree module doing hypercalls.
> >
> > With having the hypercall page present such a module would add a way to do
> > speculative attacks, while deleting the hypercall page would result in a
> > failure trying to load such a module.
> Is that a response to the original patch series, or to my suggestion?
>
> If we temporarily ask Xen to populate a hypercall page which is used
> during early boot (or even if it's *not* used, and only used to make
> sure Xen latches 64-bit mode early)... I don't see why that makes any
> difference to modules. I wasn't suggesting we keep it around and
> *export* it.
Ah, I didn't read your suggestion that way.

Still I believe using the hypercall page is not a good idea, especially as
we'd add a hard dependency on the ability to enable CFI in the kernel related
to the switch from the hypercall page to the new direct hypercall functions.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature