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
