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

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

Hello,

Le 17/12/2024 à 13:18, Xen.org security team a écrit :
> 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.
>

Should we consider adding a interface to know how to the guest is
supposed to make hypercalls (what hypercall instruction/flavor) ? Such
as the guest can have its own hypercall implementations but knows which
one to use.

> 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


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech