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


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature