[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Tue, 2025-01-07 at 09:20 +0100, Jan Beulich wrote:
> 
> How about we adjust the behavior in Xen instead: We could latch the size
> on every hypercall, making sure to invoke update_domain_wallclock_time()
> only when the size actually changed (to not incur the extra overhead),
> unless originating from the two places the latching is currently done at
> (to avoid altering existing behavior)?
>
> Then again latching more frequently (as suggested above or by any other
> model) also comes with the risk of causing issues, at the very least for
> "exotic" guests. E.g. with two vCPU-s in different modes, we'd ping-pong
> the guest between both formats then.

Indeed. I think it's much better for the guest to just write to the
hypercall page MSR early, like it always did. It doesn't even *need* to
be an executable page; just a data page which is then
freed/overwritten.

But if we *want* to use it during early boot so that we don't need all
that early CPU detection and static_call complexity, that's fine too.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.