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

[Jan Beulich <jbeulich@xxxxxxxx>]

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

Yes, putting it e.g. in .init.text ought to be possible and not violate
security requirements.

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

Hmm, this is a side effect which I fear wasn't considered when putting
together all of this. Making ourselves dependent upon ...

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

... just this may end up too little, especially when considering
transitions between OSes / OS-like environments (boot loader -> OS,
OS -> kexec-ed OS).

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

Indeed.

Jan