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

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Thu, 2025-01-02 at 15:16 +0100, Jürgen Groß wrote:
> On 02.01.25 15:06, David Woodhouse wrote:
> > On Thu, 2025-01-02 at 15:02 +0100, Jürgen Groß wrote:
> > > > Are you suggesting that you're able to enable the CPU-specific CFI
> > > > protections before you even know whether it's an Intel or AMD CPU?
> > > 
> > > Not before that, but maybe rather soon afterwards. And the hypercall page
> > > needs to be decommissioned before the next hypercall is happening. The 
> > > question
> > > is whether we have a hook in place to do that switch between cpu 
> > > identification
> > > and CFI enabling.
> > 
> > Not sure that's how I'd phrase it. Even if we have to add a hook at the
> > right time to switch from the Xen-populated hypercall page to the one
> > filled in by Linux, the question is whether adding that hook is simpler
> > than all this early static_call stuff that's been thrown together, and
> > the open questions about the 64-bit latching.
> 
> This is a valid question, yes. My first version of these patches didn't
> work with static_call, but used the paravirt call patching mechanism
> replacing an indirect call with a direct one via ALTERNATIVEs. That
> version was disliked by some involved x86 maintainers, resulting in the
> addition of the early static_call update mechanism.
> 
> One thing to mention regarding the 64-bit latching: what would you do
> with HVM domains? Those are setting up the hypercall page rather late.

In the HVM case it's from init_hypervisor_platform which is called from
slightly later in setup_arch(), so it's after static_call_init(). But
still long before HVM_PARAM_CALLBACK_IRQ is set in some cases, I think.

> In case the kernel would use CFI, enabling would happen way before the
> guest would issue any hypercall, so I guess the latching needs to happen
> by other means anyway. Or would you want to register the hypercall page
> without ever intending to use it?

I'd be tempted to do so without using it, yes. You only need to
allocate a 4KiB page, ask Xen to populate it, then free it immediately.
Or maybe just set HVM_PARAM_CALLBACK_IRQ instead, to make sure it's
done? When xen_set_upcall_vector() is called for CPU0 it does that:

        /* Trick toolstack to think we are enlightened. */
        if (!cpu)
                rc = xen_set_callback_via(1);

Maybe we just lift that out and do it somewhere unconditional, earlier?

But for PVH I'd still be inclined to set up a hypercall page early and
use it until we are able to switch.

Attachment: smime.p7s
Description: S/MIME cryptographic signature