-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

             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.

ISSUE DESCRIPTION
=================

Xen guests need to use different processor instructions to make explicit
calls into the Xen hypervisor depending on guest type and/or CPU
vendor. In order to hide those differences, the hypervisor can fill a
hypercall page with the needed instruction sequences, allowing the guest
operating system to call into the hypercall page instead of having to
choose the correct instructions.

The hypercall page contains whole functions, which are written by the
hypervisor and executed by the guest. With the lack of an interface
between the guest OS and the hypervisor specifying how a potential
modification of those functions should look like, the Xen hypervisor has
no knowledge how any potential mitigation should look like or which
hardening features should be put into place.

This results in potential vulnerabilities if the guest OS is using any
speculative mitigation that performs a compiler transform on "ret"
instructions in order to work (e.g. the Linux kernel rethunk or safe-ret
mitigations).

Furthermore, the hypercall page has no provision for Control-flow
Integrity schemes (e.g. kCFI/CET-IBT/FineIBT), and will simply
malfunction in such configurations.

IMPACT
======

Some mitigations for hardware vulnerabilities the guest OS is relying on to
work might not be fully functional, resulting in e.g. guest user processes
being able to read data they ought not have access to.

VULNERABLE SYSTEMS
==================

Only x86 systems are potentially vulnerable, Arm systems are not vulnerable.

All guest types (PV, PVH and HVM) are potentially vulnerable.

Linux guests are known to be vulnerable, guests using other operating
systems might be vulnerable, too.

MITIGATION
==========

Running only Linux guest kernels not relying on "ret" assembler instruction
patching (kernel config option CONFIG_MITIGATION_RETHUNK/CONFIG_RETHUNK
disabled) will avoid the vulnerability, as long as this option isn't
required to be safe on the underlying hardware.

CREDITS
=======

This issue was discovered by Andrew Cooper of XenServer.

RESOLUTION
==========

Applying the set of attached patches resolves this issue.

The patch to Xen is simply a documentation update to clarify that an OS author
might not want to use a hypercall page.

xsa466-linux-*.patch    Linux
xsa466-xen.patch        xen-unstable

$ sha256sum xsa466*
498fb2538f650d694bbd6b7d2333dcf9a12d0bdfcba65257a7d14c88f5b86801  xsa466-linux-01.patch
1e0d5f68d1cb4a0ef8914ae6bdeb4e18bae94c6d19659708ad707da784c0aa5c  xsa466-linux-02.patch
b3056b34c1565f901cb4ba11c03a51d4f045b5de7cd16c6e510e0bcee8cc6cd7  xsa466-linux-03.patch
0215e56739ab5b0d0ec0125f3d1806c3a0a0dcb3f562014f59b5145184a41467  xsa466-linux-04.patch
314e67060ab4f47883cf2b124d54ce3cd4b0363f0545ad907a7b754a4405aacd  xsa466-linux-05.patch
adbef75416379d96ebb72463872f993e9d8b7d119091480ad1e70fd448481733  xsa466-linux-06.patch
36874014cee5d5213610a6ffdd0e3e67d0258d28f2587b8470fdd0cef96e5013  xsa466-linux-07.patch
367f981ef8adc11b99cc6999b784305bcdcd55db0358fd6a2171509bf7f64345  xsa466-xen.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of patches or mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because the mitigation or patches need to be applied to the guests.

Deployment is permitted only AFTER the embargo ends.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmdhaxAMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZUeMH/0Qkn9G8iQWJ0fHMCxvd1lcr3RNWK5GfXqlAZvuJ
YRQMDslYCzuvzrkLnoe/P/zSSs+omEYMcOVsJCBkTqePs8yIdqwBvBfZ79I1htIu
IdyJt8SE5+b70ZlumQJ8ef1Za3lp8bxvEZVa8GIokOu0Ef1iqUKNl7tQgIoQjOUH
bV/1sFN5MNFsUshOW5DnLiRrE8j0/0nfbzHPu5H9S2B4eN38oPmTabvZG/IHky8R
VFyTvqFrKZONDDhdxyFE9PBOtP6Bu3EV+Emmxb3Q84l2oEIqgab0Xxj4QGBTuLMn
PPcU5/D6Giqx3jBMdrkMAXtBuXBYO/inqsX1IJLic9W13+A=
=wlOW
-----END PGP SIGNATURE-----