[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] XAPI can configure different users with different roles, using Role Based Access Control. For more details, see:
https://docs.xenserver.com/en-us/xencenter/current-release/rbac-overview.html#rbac-roles
The pool-admin role is fully privileged. Notably, users with this role can also SSH into the host as root.
The other administrator roles are pool-operator, vm-power-admin and vm-admin, each of which are authorised to configure and manage various aspects of the system.
Some settings are inadequately restricted, and can be set by a lower privilege of administrator than expected.
CVE-2026-23559: A vm-admin can set VBD.otherconfig:backend-local and turn arbitrary files in dom0 into VDIs (virtual disks) and give said disks to a VM they control. This is an arbitrary read and/or modify of files in dom0.
CVE-2026-23560: A vm-admin can set VM.other-config:issystemdomain and mark a VM as a system domain. System domains are ignored and left running during certain other host/pool operations, and may be hidden from view in tooling.
CVE-2026-23561: A vm-admin can set VM.otherconfig:storagedriverdomain and mark a VM as the storage domain for a particular host storage connection (PBD). Shutting down the VM can cause the PBD to be erroneously marked as unplugged when it is not.
CVE-2026-23562: Configuration of PCI passthrough is normally restricted to the pool-admin role. However one API was missing this check, allowing a vm-admin access to unintended host hardware.
CVE-2026-42486: A vm-admin can set the VM.platform:hvmserial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Xen Security Advisory CVE-2026-23556 / XSA-483 version 2
oxenstored keeps quota related use counts across domain destruction
UPDATES IN VERSION 2 ====================
Public release.
ISSUE DESCRIPTION =================
When oxenstored is tearing a domain down, the node data is cleaned up but the usage counts are leaked.
When the domain ID is eventually reused, the new domain can create fewer nodes before beeing deemed to be over quota.
IMPACT ======
Over an extended period of time, new domains will be able to create fewer and fewer nodes in xenstored, until they are eventually unable to operate at all.
A buggy or malicious domain can speed this process up by deliberately hitting it's quota, and then rebooting.
VULNERABLE SYSTEMS ==================
All versions of Xen containing the XSA-419 fixes are vulnerable.
Only systems configured to use oxenstored (Ocaml xenstored) are vulnerable. Systems configured to xenstored (C xenstored) are not vulnerable.
MITIGATION ==========
Performing a xenstore live update mitigates the issue.
CREDITS =======
This issue was discovered by Andrii Sultanov of Vates.
RESOLUTION ==========
Applying the appropriate attached patch resolves this issue.
Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.
xsa483.patch xen-unstable - Xen 4.18.x xsa483-4.17.patch Xen 4.17.x xsa483-xapi.patch XAPI oxenstored
$ sha256sum xsa483 4be3acc57dcd5e2719cab165729879757a1915c33b848a37623dd4a5f1157746 xsa483.patch 389b0411d855894adff6f640dcbd3358adc6d4cb9ddeedbcb9cb2c345af67d51 xsa483-4.17.patch ec191a1e158eddd22bfbd764f26f6b6a0b75b9fe0a223dc66da1c4a16ef73122 xsa483-xapi.patch $
DEPLOYMENT DURING EMBARGO =========================
Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.
But: Distribution of updated software is prohibited (except to other members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.
(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/4UyVfoK9kFAmnwoPIMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZM8EH/iXC6hLQHAVLeRCfUEZ1ncM7029KPyRxLIOlthCS cAyMNjyVSckGMRgKvYWCpl/fN1v/2yv3olIIR9wtncaq8Q+iMkwOsw1P46fmsh3J 40pK6PnaP1/kRrua1ZANlUc8YUhWG8fE2ADPHCIo57qbO1fXVUEWARdgU5gYIkF4 Kz+dvkpEEiTdRe24zqfn9Bv4lDsihfq3B9zecEuqMj3L88FrMP9VfBJZMbx9N/Pb TUE/FltETdWqMLeIyb7r3P5OPrLRYk6ebgrX96Pb3f0d1/OC8E4Me3RNvGoArmOI f8R0M/zly0lmoJspJFtI2C7BdUIKB/59z/Sz2YC706AJBO0= =mbDG -----END PGP SIGNATURE-----
On 06/03/2025 4:48 am, Solar Designer wrote: Under Host UEFI Secure Boot, there is a security boundary between kernel code and root. Part of the requirement is "no unsigned code running privileged", and while this is technically a grey area (the malicious blob is signed; it's just not signed by AMD), it's also easy to argue that root definitely shouldn't be able to load a malicious microcode, just like it shouldn't be able to swap out the kernel with an unsigned one and reboot. Yes, but can't Xen's and the kernel's new protections be bypassed by MSR access via /dev/cpu//msr? The AMD microcode loader released by Google now doesn't appear to require more than that:
https://github.com/google/security-research/blob/master/pocs/cpus/entrysign/zentool/loader.c For Linux, /dev/cpu//msr isn't available when lockdown mode is active.
For Xen, guests can't load microcode at all (writes to the relevant MSRs are simply swallowed). Actually loading microcode is done via hypercall, restricted to privileged domains, and digest checking can't be disabled without a reboot (or a livepatch, which in a UEFI-SB model needs to itself be signed).
Answering Bastian's question from the other fork of this thread (sorry, I'm not CC'd).
Maintaining the hash list is a concern, but in the immediate term, the relevant maintainers in Linux and Xen.
Something better is being worked on, but there are challenges beyond just technical ones.
~Andrew
On Wed, Mar 05, 2025 at 07:11:23PM +0000, Andrew Cooper wrote: See:
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html
Right now there are four known but (reasonably) benign microcodes from a non-AMD source. However, there is a tool to sign arbitrary microcode.
In Xen, we've provided a stopgap mitigation to perform extra checks on microcode load on affected CPU families. This is a SHA2 digest check against hashes with believed-good provenance. This is staging only for now, in case it is overly disruptive.
This will not protect against an already-compromised platform, but it will prevent an uncompromised system becoming compromised via Xen's microcode loading capabilities. Thank you, Andrew!
Maybe you can also clarify what Xen's threat model is here, and how this mitigation fits into it?
Specifically, what are "Xen's microcode loading capabilities" and are they in any way more exposed than the host system's root account? Even with Xen's mitigation above, host root can still load microcode without Xen involvement, right? Unless you block (at least) MSR access and kernel module loading?
Also, by "uncompromised system", do you specifically mean uncompromised at microcode level? If the threat is from a Xen administrator, then perhaps that's a partial security compromise already, just not yet extended to microcode.
These things may be obvious to someone more familiar with Xen, but your message and answers to the above are also interesting to the rest of us. On affected systems, the only complete fix is a firmware update. This is a very firmly recommended course of action.
Sincerely,
~Andrew, on behalf of the Xen Security Team. Alexander
On 12/11/2024 5:17 pm, Demi Marie Obenour wrote: On Tue, Nov 12, 2024 at 12:05:47PM +0000, Xen Security wrote: Only PVH guests can leverage the vulnerability. HVM and PV guests cannot leverage the vulnerability. Note that PV guests when run inside the (PVH) shim can't leverage the vulnerability. Is this unconditional (perhaps because the relevant data gets zeroed out by the shim), or does it only apply when the PV guest can't extract data from the shim's memory? For instance, 32-bit PV guests aren't security supported anymore, but the PV shim isn't supposed to rely on the security of the shim itself, only of the rest of the system. Data are leaked into the PVShim guest, but it is the shim Xen (exclusively) which has access to the ACPI tables.
The guest which has been shim'd can't architecturally access the leaked data.
~Andrew
For a brief summary of Xapi terminology, see:
https://xapi-project.github.io/xen-api/overview.html#object-model-overview
Xapi contains functionality to backup and restore metadata about Virtual Machines and Storage Repositories (SRs).
The metadata itself is stored in a Virtual Disk Image (VDI) inside an SR. This is used for two purposes; a general backup of metadata (e.g. to recover from a host failure if the filer is still good), and Portable SRs (e.g. using an external hard drive to move VMs to another host).
Metadata is only restored as an explicit administrator action, but occurs in cases where the host has no information about the SR, and must locate the metadata VDI in order to retrieve the metadata.
The metadata VDI is located by searching (in UUID alphanumeric order) each VDI, mounting it, and seeing if there is a suitable metadata file present. The first matching VDI is deemed to be the metadata VDI, and is restored from.
In the general case, the content of VDIs are controlled by the VM owner, and should not be trusted by the host administrator.
A malicious guest can manipulate its disk to appear to be a metadata backup.
A guest cannot choose the UUIDs of its VDIs, but a guest with one disk has a 50% chance of sorting ahead of the legitimate metadata backup. A guest with two disks has a 75% chance, etc.
An attacker with local access to a system (either through a disk or external drive) can present a modified XFS partition to grub-legacy in such a way to exploit a memory corruption in grub’s XFS file system implementation.
On 2023-10-03 22:37:08 +0100 (+0100), Andrew Cooper wrote: [...] If you have a proposal for how you'd prefer it to be done, I'll see what I can do. Perhaps BCC oss-security, or just send out a second mail? When I send advisories, I prepare two basically identical E-mail messages: one to the project's announcement list and one to oss-security (signing both of them). It seems like this is the most common approach to avoiding cross-posting between lists. -- Jeremy Stanley
On 26/09/2023 5:09 pm, Solar Designer wrote: On Tue, Sep 26, 2023 at 01:15:55AM +0100, Andrew Cooper wrote: On 25/09/2023 7:28 pm, Solar Designer wrote: Maybe directly probing for the bug is an option? Perhaps can be done within one thread (where the bug doesn't have security impact, but is detectable anyway, no)? Unfortunately, direct probing is usually the wrong thing to rely on.
Under virt, one common scenario is that you boot on one system, then get migrated to a different one. Obviously, it's up to the hypervisor to ensure that the architectural feature still match, but the microarchitecture really does change.
If you probe at boot and positively identify an issue to work around, great. But as a VM you may not get a heads up that you changed microarchitecture, and even if you do, you don't rescan for everything you ran at boot.
The CPUID bits allow microarchitectural details to be expressed as architectural, and allow a hypervisor to state "here or someone you might move to, the following safety property does not hold." I was thinking re-probing after possible VM migration, just like you would presumably retest a CPUID bit. I did enquire about this, but the Linux maintainers and Microsoft were distinctly unreceptive to the idea. Not that I blame them - it's hard enough to do late microcode loading, livepatching and activation of new safety properties when the uarch isn't moving underfoot. However, in this case probing can lead to false negatives if the other thread issues a DIV too or an unexpected context switch occurs. Yes, many things become racy under virt, hence why we try our best to stick to architecturally enumerated properties. Do you know if only the quotient leaks, or also the remainder? In the below, I assume the remainder leaks as well. I'm afraid I don't know. The original paper says just the quotient, but it also says there are no leaks across privilege boundaries. Is the original paper public? https://www.usenix.org/system/files/usenixsecurity23-hofmann.pdf
Section 8.2.1 for the results specific to divides. Meanwhile, I observe a difference between Linux and Xen fixes - Linux uses native-sized DIV and you use byte-sized, as a clever way not to clobber RDX and maybe achieve lower latency. Speaking of which:
$ git clone https://github.com/InstLatx64/InstLatx64 $ grep -r ': DIV . 0/' InstLatx64/AuthenticAMD/Zen.txt InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 409 X86 : DIV r8 0/ 8b L: [no true dep.] T: 4.14ns= 13.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 413 X86 : DIV r8 0/ 4b L: [no true dep.] T: 4.13ns= 13.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 422 X86 : DIV r16 0/16b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 426 X86 : DIV r16 0/ 8b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 435 X86 : DIV r32 0/32b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 439 X86 : DIV r32 0/16b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 449 AMD64 : DIV r64 0/64b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 453 AMD64 : DIV r64 0/32b L: [no true dep.] T: 4.45ns= 14.00c
Looks like maybe not that much difference, after all, if this data applies. Agner Fogh's manuals have a little more information, and importantly give the upper bound which tops out at 47 cycles.
There is at least a 1 cycle change in latency between the byte and non-byte forms, which I suspect is down to the non-byte forms needing to consume an extra input register before starting.
But the main reason for choosing the byte form is indeed fewer moving parts to worry about in the critical sections, where one wrong instruction can render all protections moot. Thank you for sharing so much detail and thoughts on this, Andrew! You're welcome.
~Andrew
On Tue, Sep 26, 2023 at 01:15:55AM +0100, Andrew Cooper wrote: On 25/09/2023 7:28 pm, Solar Designer wrote: Maybe directly probing for the bug is an option? Perhaps can be done within one thread (where the bug doesn't have security impact, but is detectable anyway, no)? Unfortunately, direct probing is usually the wrong thing to rely on.
Under virt, one common scenario is that you boot on one system, then get migrated to a different one. Obviously, it's up to the hypervisor to ensure that the architectural feature still match, but the microarchitecture really does change.
If you probe at boot and positively identify an issue to work around, great. But as a VM you may not get a heads up that you changed microarchitecture, and even if you do, you don't rescan for everything you ran at boot.
The CPUID bits allow microarchitectural details to be expressed as architectural, and allow a hypervisor to state "here or someone you might move to, the following safety property does not hold." I was thinking re-probing after possible VM migration, just like you would presumably retest a CPUID bit. However, in this case probing can lead to false negatives if the other thread issues a DIV too or an unexpected context switch occurs. Do you know if only the quotient leaks, or also the remainder? In the below, I assume the remainder leaks as well. I'm afraid I don't know. The original paper says just the quotient, but it also says there are no leaks across privilege boundaries. Is the original paper public?
Meanwhile, I observe a difference between Linux and Xen fixes - Linux uses native-sized DIV and you use byte-sized, as a clever way not to clobber RDX and maybe achieve lower latency. Speaking of which:
$ git clone https://github.com/InstLatx64/InstLatx64 $ grep -r ': DIV . 0/' InstLatx64/AuthenticAMD/Zen.txt InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 409 X86 : DIV r8 0/ 8b L: [no true dep.] T: 4.14ns= 13.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 413 X86 : DIV r8 0/ 4b L: [no true dep.] T: 4.13ns= 13.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 422 X86 : DIV r16 0/16b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 426 X86 : DIV r16 0/ 8b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 435 X86 : DIV r32 0/32b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 439 X86 : DIV r32 0/16b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 449 AMD64 : DIV r64 0/64b L: [no true dep.] T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 453 AMD64 : DIV r64 0/32b L: [no true dep.] T: 4.45ns= 14.00c
Looks like maybe not that much difference, after all, if this data applies.
Thank you for sharing so much detail and thoughts on this, Andrew!
Alexander
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Xen Security Advisory CVE-2023-20588 / XSA-439 version 2
x86/AMD: Divide speculative information leak
UPDATES IN VERSION 2 ====================
Version 1 accidentally linked to the wrong AMD bulletin. This has been corrected in v2. All other information in v1 is believed to be correct.
ISSUE DESCRIPTION =================
In the Zen1 microarchitecure, there is one divider in the pipeline which services uops from both threads. In the case of #DE, the latched result from the previous DIV to execute will be forwarded speculatively.
This is a covert channel that allows two threads to communicate without any system calls. In also allows userspace to obtain the result of the most recent DIV instruction executed (even speculatively) in the core, which can be from a higher privilege context.
For more information, see: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7007.html
IMPACT ======
An attacker might be able to infer data from a different execution context on the same CPU core.
VULNERABLE SYSTEMS ==================
All versions of Xen are vulnerable.
Only AMD Zen1 CPUs are believed to be vulnerable.
MITIGATION ==========
There is no mitigation.
RESOLUTION ==========
The patches for Xen overwrite the buffer in the divider on the return-to-guest path.
However, as with some prior speculative vulnerabilities, the fix is only effective in combination with disabling SMT. For the same reasons as before, Xen does not disable SMT by default.
The system administrator is required to risk-assess their workload, and choose whether to enable or disable SMT. Xen will issue a warning if SMT is active and the user has not provided an explicit choice via the smt=<bool> command line option.
Details of the vulnerability became public before the Xen patches were complete. Hence the patches are already applied to the appropriate trees. They are:
Xen-unstable: 1c18d7377453^..b5926c6ecf05 Xen 4.17: d2d2dcae879c^..9ac2f49f5fa3 Xen 4.16: 08539e8315fd^..de751c3d906d Xen 4.15: db3386e6cad6^..d7b78041dc81 -----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmURwLwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZMjgIAI+pm7OnUq8EbuD6eyB7yDKBRwm9U7Hu2yrO47f0 CHO/HdMANfx0nCbpKS8+7GXa2gooJXgp3Fo0NGri2G0+hzXNQTsaGnMEMgBV7O0M OXYzao39dhPATP4hi5bm0xPTZ+3zMaP06xvl7JqNqsPK8GFz/cZr/Hsz5r2boZRO 3FXEmbgsG2KTR5+HrSNoeA3LM9aoUqEiIq6oGxLaTr7UI6xK4FL5VFloWhS0r9yp gD7HHP6NlV1Ysxt1xKCxf109HrzWEvih/Gd8hG6eqiHR+i2zyS1hna8Ll/sRFkOO x9FpYHljtb3WKX9bUh4aZXdoAWRW0aR+SWcXToPSk5aFJiE= =W6vz -----END PGP SIGNATURE-----
On 16/08/2023 5:41 pm, Solar Designer wrote: On Tue, Aug 08, 2023 at 07:18:51PM +0100, Andrew Cooper wrote: On 08/08/2023 7:00 pm, Solar Designer wrote: + / + Microcode is the preferred mitigation, in terms of performance. + However, without microcode, this chickenbit (specific to the Zen2 + uarch) disables Floating Point Mov-Elimination to mitigate the + issue. + / + val &= ~chickenbit; + if (sig->rev < goodrev) + val |= chickenbit;
This leaves me wondering: why have this line at all? I understand Xen wanting to enable the chicken bit on vulnerable CPUs, but why disable it on other AMD CPUs? If someone or something had enabled the bit, that's probably intentional, and even if not it probably shouldn't be Xen's business to alter CPU behavior beyond what's necessary for Xen itself to work reliably and securely.
Am I missing something? There is an earlier exit in this function for any non-Zen2 system.
So here, we are strictly on Zen2 (all vulnerable), and either have good microcode or not.
The microcode fix is far more performant than the chickenbit. Sure, but that's orthogonal to my concern, which was about areas of responsibility and control (such as sysadmin vs. tools).
Anyway, it was pointed out to me off-list that Linux kernel does the same thing, also explicitly disabling chickenbit when deemed safe:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=522b1d69219d8f083173819fde04f994aa051a98
+ if (!cpuhaszenbleedmicrocode()) { + prnoticeonce("Zenbleed: please update your microcode for the most optimal fix\n"); + msrsetbit(MSRAMD64DECFG, MSRAMD64DECFGZEN2FPBACKUPFIXBIT); + } else { + msrclearbit(MSRAMD64DECFG, MSRAMD64DECFGZEN2FPBACKUPFIXBIT); + }
So at least it's a consistent approach by these two projects, and a reason for Xen to be doing it this way. It is not a coincidence that Xen and Linux are similar here. The areas of responsibility aspect was raised during review - we did consider combining with the old value.
AMD's position AIUI is that prior to Zenbleed, this bit was unsupported and not used. Therefore we went for the simpler approach (and as you saw, still managed to screw that up).
~Andrew
On 08/08/2023 7:00 pm, Solar Designer wrote: On Mon, Jul 31, 2023 at 05:00:35PM +0000, Xen. org security team wrote: The patch provided with earlier versions was buggy. It unintentionally disable more bits than expected in the control register. The contents of this register is not generally known, so the effects on the system are unknown.
A patch correcting this error has been committed and backported to all stable trees which got the XSA-433 fix originally. Additionally, it is attached to this advisory as xsa433-bugfix.patch, and applicable to all branches in this form. where xsa433-bugfix.patch includes this description: This line:
val &= ~chickenbit;
ends up truncating val to 32 bits, and turning off various errata workarounds in Zen2 systems. and that patch then corrects the truncation by changing the type of the chickenbit variable to 64-bit. The context is:
+ / + Microcode is the preferred mitigation, in terms of performance. + However, without microcode, this chickenbit (specific to the Zen2 + uarch) disables Floating Point Mov-Elimination to mitigate the + issue. + / + val &= ~chickenbit; + if (sig->rev < goodrev) + val |= chickenbit;
This leaves me wondering: why have this line at all? I understand Xen wanting to enable the chicken bit on vulnerable CPUs, but why disable it on other AMD CPUs? If someone or something had enabled the bit, that's probably intentional, and even if not it probably shouldn't be Xen's business to alter CPU behavior beyond what's necessary for Xen itself to work reliably and securely.
Am I missing something? There is an earlier exit in this function for any non-Zen2 system.
So here, we are strictly on Zen2 (all vulnerable), and either have good microcode or not.
The microcode fix is far more performant than the chickenbit.
This chickenbit is something unrelated to FP move-elimination on other microarchitectures.
~Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Xen Security Advisory CVE-2023-20569 / XSA-434
x86/AMD: Speculative Return Stack Overflow
ISSUE DESCRIPTION =================
Researchers from ETH Zurich have extended their prior research (XSA-422, Branch Type Confusion, a.k.a Retbleed) and have discovered INCEPTION, also know as RAS (Return Address Stack) Poisoning, and Speculative Return Stack Overflow.
The RAS is updated when a CALL instruction is predicted, rather than at a later point in the pipeline. However, the RAS is still fundamentally a circular stack.
It is possible to poison the branch type and target predictions such that, at a point of the attackers choosing, the branch predictor predicts enough CALLs back-to-back to wrap around the entire RAS and overwrite a correct return prediction with one of the attackers choosing.
This allows the attacker to control RET speculation in a victim context, and leak arbitrary data as a result.
For more details, see: https://comsec.ethz.ch/inception https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-7005
IMPACT ======
An attacker might be able to infer the contents of memory belonging to other guests.
VULNERABLE SYSTEMS ==================
Only CPUs from AMD are believed to be potentially vulnerable. CPUs from other manufacturers are not believed to be impacted.
At the time of writing, all in-support AMD CPUs (that is, Zen1 thru Zen4 microarchitectures) are believed to be potentially vulnerable. Older CPUs have not been analysed.
By default following XSA-422, Xen mitigates BTC on AMD Zen2 and older CPUs by issuing an IBPB on entry to Xen. On Zen2 and older CPUs, this is believed to be sufficient to protect against SRSO too.
AMD Zen3 and Zen4 CPUs are susceptible to SRSO too. All versions of Xen are vulnerable on these CPUs.
MITIGATION ==========
On Zen3 and Zen4, there is no mitigation.
RESOLUTION ==========
AMD are producing microcode updates for Zen3 and Zen4. Consult your dom0 OS vendor.
With the microcode update applied, booting Xen with spec-ctrl=ibpb-entry is sufficient to protect against SRSO.
The appropriate set of patches will default to using IBPB-on-entry on Zen3 and Zen4 CPUs, as well as synthesise new CPUID bits for guests to use in order to determine their susceptibility in a migration-safe way.
The patches for this issue interact texturally but not logically with the fixes for XSA-435, which itself has complexities. See XSA-435 for details of how to obtain the fixes. -----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmTSZOsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ8uMIAL2xBV/B3O0t90aFhX75dOWZBUkujMN0xHDjyI+c lnEmy44QnX+jI9IBSuc4qaJmLXnUO71WsMU1XeKucOnh9E1kjgHB2H0GgS+GI6dG LtAVxn+RRK39YIO0CHAXvr/tlX/eyodvxtmxOKLRY47J0hHLToXBEdc2VfXrUEfk 8AZn4hhHDGfRMX7jguxPFnrKCS3sZCFn1FYPtUxNGi2BbUzFacc+zZ2OISR7C59H 24q9UIgUVoVwOnUWBEzW6oHmjP44Q0kG3E8LhZQhr1YkAG++KapgTPllc3cU4xja G8ozTeMeyVbM29EMS7QknOlkvMSUmtgzNg7Pt6El9oSyuH4= =rrcN -----END PGP SIGNATURE-----
XAPI open file limit DoS It is possible for an unauthenticated client on the network to cause XAPI to hit its file-descriptor limit. This causes XAPI to be unable to accept new requests for other (trusted) clients, and blocks XAPI from carrying out any tasks that require the opening of file descriptors.
grant table v2 status pages may remain accessible after de-allocation (take two) Guest get permitted access to certain Xen-owned pages of memory. The majority of such pages remain allocated / associated with a guest for its entire lifetime. Grant table v2 status pages, however, get de-allocated when a guest switched (back) from v2 to v1. The freeing of such pages requires that the hypervisor know where in the guest these pages were mapped. The hypervisor tracks only one use within guest space, but racing requests from the guest to insert mappings of these pages may result in any of them to become mapped in multiple locations. Upon switching back from v2 to v1, the guest would then retain access to a page that was freed and perhaps re-used for other purposes. This bug was fortuitously fixed by code cleanup in Xen 4.14, and backported to security-supported Xen branches as a prerequisite of the fix for XSA-378.
PoD operations on misaligned GFNs T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). The implementation of some of these hypercalls for PoD does not enforce the base page frame number to be suitably aligned for the specified order, yet some code involved in PoD handling actually makes such an assumption. These operations are XENMEMdecreasereservation (CVE-2021-28704) and XENMEMpopulatephysmap (CVE-2021-28707), the latter usable only by domains controlling the guest, i.e. a de-privileged qemu or a stub domain. (Patch 1, combining the fix to both these two issues.) In addition handling of XENMEMdecreasereservation can also trigger a host crash when the specified page order is neither 4k nor 2M nor 1G (CVE-2021-28708, patch 2).
guests may exceed their designated memory limit When a guest is permitted to have close to 16TiB of memory, it may be able to issue hypercalls to increase its memory allocation beyond the administrator established limit. This is a result of a calculation done with 32-bit precision, which may overflow. It would then only be the overflowed (and hence small) number which gets compared against the established upper bound.
PoD operations on misaligned GFNs T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). The implementation of some of these hypercalls for PoD does not enforce the base page frame number to be suitably aligned for the specified order, yet some code involved in PoD handling actually makes such an assumption. These operations are XENMEMdecreasereservation (CVE-2021-28704) and XENMEMpopulatephysmap (CVE-2021-28707), the latter usable only by domains controlling the guest, i.e. a de-privileged qemu or a stub domain. (Patch 1, combining the fix to both these two issues.) In addition handling of XENMEMdecreasereservation can also trigger a host crash when the specified page order is neither 4k nor 2M nor 1G (CVE-2021-28708, patch 2).
PoD operations on misaligned GFNs T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). The implementation of some of these hypercalls for PoD does not enforce the base page frame number to be suitably aligned for the specified order, yet some code involved in PoD handling actually makes such an assumption. These operations are XENMEMdecreasereservation (CVE-2021-28704) and XENMEMpopulatephysmap (CVE-2021-28707), the latter usable only by domains controlling the guest, i.e. a de-privileged qemu or a stub domain. (Patch 1, combining the fix to both these two issues.) In addition handling of XENMEMdecreasereservation can also trigger a host crash when the specified page order is neither 4k nor 2M nor 1G (CVE-2021-28708, patch 2).
issues with partially successful P2M updates on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). In some cases the hypervisor carries out the requests by splitting them into smaller chunks. Error handling in certain PoD cases has been insufficient in that in particular partial success of some operations was not properly accounted for. There are two code paths affected - page removal (CVE-2021-28705) and insertion of new pages (CVE-2021-28709). (We provide one patch which combines the fix to both issues.)
issues with partially successful P2M updates on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). In some cases the hypervisor carries out the requests by splitting them into smaller chunks. Error handling in certain PoD cases has been insufficient in that in particular partial success of some operations was not properly accounted for. There are two code paths affected - page removal (CVE-2021-28705) and insertion of new pages (CVE-2021-28709). (We provide one patch which combines the fix to both issues.)
certain VT-d IOMMUs may not work in shared page table mode For efficiency reasons, address translation control structures (page tables) may (and, on suitable hardware, by default will) be shared between CPUs, for second-level translation (EPT), and IOMMUs. These page tables are presently set up to always be 4 levels deep. However, an IOMMU may require the use of just 3 page table levels. In such a configuration the lop level table needs to be stripped before inserting the root table's address into the hardware pagetable base register. When sharing page tables, Xen erroneously skipped this stripping. Consequently, the guest is able to write to leaf page table entries.
PCI devices with RMRRs not deassigned correctly Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR"). These are typically used for platform tasks such as legacy USB emulation. If such a device is passed through to a guest, then on guest shutdown the device is not properly deassigned. The IOMMU configuration for these devices which are not properly deassigned ends up pointing to a freed data structure, including the IO Pagetables. Subsequent DMA or interrupts from the device will have unpredictable behaviour, ranging from IOMMU faults to memory corruption.
Another race in XENMAPSPACEgranttable handling Guests are permitted access to certain Xen-owned pages of memory. The majority of such pages remain allocated / associated with a guest for its entire lifetime. Grant table v2 status pages, however, are de-allocated when a guest switches (back) from v2 to v1. Freeing such pages requires that the hypervisor enforce that no parallel request can result in the addition of a mapping of such a page to a guest. That enforcement was missing, allowing guests to retain access to pages that were freed and perhaps re-used for other purposes. Unfortunately, when XSA-379 was being prepared, this similar issue was not noticed.
IOMMU page mapping issues on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Both AMD and Intel allow ACPI tables to specify regions of memory which should be left untranslated, which typically means these addresses should pass the translation phase unaltered. While these are typically device specific ACPI properties, they can also be specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the identity mappings would be left in place, allowing a guest continued access to ranges of memory which it shouldn't have access to anymore (CVE-2021-28696).
IOMMU page mapping issues on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Both AMD and Intel allow ACPI tables to specify regions of memory which should be left untranslated, which typically means these addresses should pass the translation phase unaltered. While these are typically device specific ACPI properties, they can also be specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the identity mappings would be left in place, allowing a guest continued access to ranges of memory which it shouldn't have access to anymore (CVE-2021-28696).
IOMMU page mapping issues on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Both AMD and Intel allow ACPI tables to specify regions of memory which should be left untranslated, which typically means these addresses should pass the translation phase unaltered. While these are typically device specific ACPI properties, they can also be specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the identity mappings would be left in place, allowing a guest continued access to ranges of memory which it shouldn't have access to anymore (CVE-2021-28696).
grant table v2 status pages may remain accessible after de-allocation Guest get permitted access to certain Xen-owned pages of memory. The majority of such pages remain allocated / associated with a guest for its entire lifetime. Grant table v2 status pages, however, get de-allocated when a guest switched (back) from v2 to v1. The freeing of such pages requires that the hypervisor know where in the guest these pages were mapped. The hypervisor tracks only one use within guest space, but racing requests from the guest to insert mappings of these pages may result in any of them to become mapped in multiple locations. Upon switching back from v2 to v1, the guest would then retain access to a page that was freed and perhaps re-used for other purposes.
long running loops in grant table handling In order to properly monitor resource use, Xen maintains information on the grant mappings a domain may create to map grants offered by other domains. In the process of carrying out certain actions, Xen would iterate over all such entries, including ones which aren't in use anymore and some which may have been created but never used. If the number of entries for a given domain is large enough, this iterating of the entire table may tie up a CPU for too long, starving other domains or causing issues in the hypervisor itself. Note that a domain may map its own grants, i.e. there is no need for multiple domains to be involved here. A pair of "cooperating" guests may, however, cause the effects to be more severe.