[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |