Accesses to the CMOS memory contents are done using an indirect IO port pair. Therefore Xen needs to cache the guest chosen index, and one of the usages of the index didn't take the necessary locking to avoid concurrent changes. As a result, a guest could change the index after it being checked, causing a subsequent out-of-bound read access to the contents of an array.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away.

Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held.

The v1 -> v2 issue is CVE-2026-62435.

The v2 -> v1 issue is CVE-2026-62436.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

To manage the system, sysctl and platform operations are used by the control domain or a possible Xenstore domain. Some of these operations may not be executed in parallel, so a system-wide lock each is used. The way those locks are acquired is, however, not providing any fairness. Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking.

The sysctl issue is CVE-2026-62426.

The platform-op issue is CVE-2026-62427.

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

Xen Security Advisory CVE-2026-42493 / XSA-495 version 2

x86 shadow paging is deprecated

UPDATES IN VERSION 2 ====================

Updated the patch for staging with further CI adjustements.

Public release.

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

Addressing certain issues, in particular related to operations which may take excessively long and therefore would need preemption, has turned out overly costly. Since alternatives (HVM/PVH: HAP, PV: shim) are commonly available, the decision was to deprecate the functionality, while still retaining it for people to use at their own (security) risk. Memory-wise small enough guests may still be okay to run.

IMPACT ======

An unprivileged guest may be able to cause Denial of Service (DoS) affecting the entire host.

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

All x86 systems with builds of Xen having SHADOWPAGING=y are affected. Note that prior to Xen 4.7 this control didn't exist, and all builds of Xen would be affected. (Strictly speaking Xen 4.6 had a different, harder to use mechanism to disable shadow paging support: One could pass "shadow-paging=n" on the make command line.)

MITIGATION ==========

Running HVM and PVH in Hardware Assisted Paging (HAP) mode will avoid this vulnerability.

There's no mitigation available for PV guests. This is because shadow mode, if support is enabled in the hypervisor, could be engaged at any time. Note that without shadow mode built into Xen, guests not properly dealing with L1TF will simply be crashed instead.

RESOLUTION ==========

Applying the appropriate attached patch documents 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.

xsa495.patch xen-unstable - Xen 4.22.0 xsa495-4.21.patch Xen 4.21.x xsa495-4.20.patch Xen 4.20.x - Xen 4.19.x xsa495-4.18.patch Xen 4.18.x xsa495-4.17.patch Xen 4.17.x

$ sha256sum xsa495 949624ce241ddc455c43cdde0ff045cc5fdf29b69f06f7079fa8f1d2400e1d9d xsa495.patch bb1fea4b49840b81a1a7ca86124e308f23edd6eb078857d44d9ebaf1b352b374 xsa495-4.17.patch 06f2c862df85a17b9dc1d4a0df42cadb97e24b7033c070c9ad74ad72d278af0e xsa495-4.18.patch bffa5816be9ddf0fabec0509f2b74e30a5dd0e5429a3b7919e304150cb5091f2 xsa495-4.20.patch 7092cf37dbcfecc9aa6bf9a2836ed70f48f52bccb9630e94c89d2afe120b47f5 xsa495-4.21.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 switching HVM or PVH guests from shadow to HAP mode is a guest noticeable change, while for PV guests the lack of shadow mode is noticeable because they then cannot be migrated anymore, and guests not properly fixed for L1TF would be forcibly crashed.

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/4UyVfoK9kFAmpomqUMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZH9wH/2EYJsV5YVdJsoQSlG94dqOR7IDPEI2I17wUVSoG OK6BaqaejA1SHJbt0/wSkhJ9er+1UHzgr61S7EnE813mugu7T9nwTku1/++4DB9O V/ID/NZzWwGJ2EjCHGrVTPZvmxMmVBGZs3bex00xrQ83y97D3TfmCRH0k6ip7sUh kKSmdvTdlnODuV1+3KT09RIpDvOjVGXLpnd22++0CcT0eFoOrn0nH2dgdUw/grTf 7ye6pGcj2xViznw7FDJnXG4XOAC+wIBMX9HJK6rMOFR9P2DFUxUEcYVN+DlzR67h 3Mejc9U4Ll+65RoZbI01lmpnpqEJ33kPRGkwzA0CJmkF8wQ= =evRY -----END PGP SIGNATURE-----

When passing through PCI devices, the detach logic in libxl won't remove access permissions to any 64bit memory BARs the device might have. As a result a domain can still have access any 64bit memory BAR when such device is no longer assigned to the domain.

For PV domains the permission leak allows the domain itself to map the memory in the page-tables. For HVM it would require a compromised device model or stubdomain to map the leaked memory into the HVM domain p2m.

Unlike 32-bit PV guests, HVM guests may switch freely between 64-bit and other modes. This in particular means that they may set registers used to pass 32-bit-mode hypercall arguments to values outside of the range 32-bit code would be able to set them to.

When processing of hypercalls takes a considerable amount of time, the hypervisor may choose to invoke a hypercall continuation. Doing so involves putting (perhaps updated) hypercall arguments in respective registers. For guests not running in 64-bit mode this further involves a certain amount of translation of the values.

Unfortunately internal sanity checking of these translated values assumes high halves of registers to always be clear when invoking a hypercall. When this is found not to be the case, it triggers a consistency check in the hypervisor and causes a crash.

Because of a logical error in XSA-407 (Branch Type Confusion), the mitigation is not applied properly when it is intended to be used. XSA-434 (Speculative Return Stack Overflow) uses the same infrastructure, so is equally impacted.

For more details, see: https://xenbits.xen.org/xsa/advisory-407.html https://xenbits.xen.org/xsa/advisory-434.html

Recent x86 CPUs offer functionality named Control-flow Enforcement Technology (CET). A sub-feature of this are Shadow Stacks (CET-SS). CET-SS is a hardware feature designed to protect against Return Oriented Programming attacks. When enabled, traditional stacks holding both data and return addresses are accompanied by so called "shadow stacks", holding little more than return addresses. Shadow stacks aren't writable by normal instructions, and upon function returns their contents are used to check for possible manipulation of a return address coming from the traditional stack.

In particular certain memory accesses need intercepting by Xen. In various cases the necessary emulation involves kind of replaying of the instruction. Such replaying typically involves filling and then invoking of a stub. Such a replayed instruction may raise an exceptions, which is expected and dealt with accordingly.

Unfortunately the interaction of both of the above wasn't right: Recovery involves removal of a call frame from the (traditional) stack. The counterpart of this operation for the shadow stack was missing.

On Thu, Mar 06, 2025 at 04:11:25AM +0000, Andrew Cooper wrote: On 06/03/2025 3:15 am, Solar Designer wrote: 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? First of all, there's an equivalent change in Linux.

https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb2281fb05e50108ce95c43ab7e701ee564565c8 Oh, I had missed that, thanks! [...] 3rd party repositories of microcode repositories ripped out of firmware exist, there is a small but known usergroup who take microcode from a 3rd party source.

As of today, anyone can make an arbitrary malicious microcode that will load on Zen1-4 CPUs.

This issue wins points for spite, because the highest risk users are the ones who were taking proactive steps to try and improve their security, betting that AMD's patchloader crypto was sound. OK, so this is to protect legitimate sysadmins from loading malicious microcode inadvertently or via a supply chain attack. Makes sense. 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 In Xen we're working towards properly supporting UEFI Secure Boot.  We're not there yet (there's a lot of technical debt to overcome), hence why this isn't a full-blown XSA.

All of that said, it's also likely that there are a lot of vulnerable but uncompromised systems.  These measures in Xen and Linux are a stopgap; a bit of extra defence in depth.  They're certainly not perfect. OK. Thanks again,

Alexander

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. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab

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

Xen Security Advisory CVE-2023-46837 / XSA-447 version 2

arm32: The cache may not be properly cleaned/invalidated (take two)

UPDATES IN VERSION 2 ====================

Public release.

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

Arm provides multiple helpers to clean & invalidate the cache for a given region. This is, for instance, used when allocating guest memory to ensure any writes (such as the ones during scrubbing) have reached memory before handing over the page to a guest.

Unfortunately, the arithmetics in the helpers can overflow and would then result to skip the cache cleaning/invalidation. Therefore there is no guarantee when all the writes will reach the memory.

This undefined behavior was meant to be addressed by XSA-437, but the approach was not sufficient.

IMPACT ======

A malicious guest may be able to read sensitive data from memory that previously belonged to another guest.

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

Systems running all version of Xen are affected.

Only systems running Xen on Arm 32-bit are vulnerable. Xen on Arm 64-bit is not affected.

MITIGATION ==========

There is no known mitigation.

CREDITS =======

This issue was discovered by Michal Orzel from AMD.

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.

xsa447/xsa447.patch xen-unstable - Xen 4.17.x xsa447/xsa447-4.16.patch Xen 4.16.x - Xen 4.15.x

$ sha256sum xsa447 xsa447/ 639f3a30124fd0f45b6b68768c02a5b5aa2e78c6c1f28bbf1ea5fb9be1f874af xsa447.meta 0816717ab6e9c2250975ed1100bb2943830dc10e9a52aed7dd5cbe1884a15918 xsa447/xsa447.patch f325543852b28af3fb2a2ca501a70fc59d3b35432334d52f734b2071c8a9667f xsa447/xsa447-4.16.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/4UyVfoK9kFAmV4SxMMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZvnUIAIG4NNqHQCeBV0VOLtdZLNgaBDt9Vguc4FLUYlI5 aBc4/IWrsGYYRuBzLAPGoKYP9/F+OjiHcE0ClFnxkQJ+bFKl4SQLxmSksHkvPtpo 6yL53IbyraIbA+TulYquTr27v7ZnTI9LQA3VurD6sMgiWIo8+C/kSb6g/1TAsm4R qzHDRLhTd4H+yU7KV327qIUk1D4S0eGP1yWpudpd0A/05RBgI9m4gp01VFeJn8w+ UbYba/4LpcAKG/iyvxqk5o3fyO60zhZEc5BBHhcz7DJ+UvLrLf7TDLrkaI6lorye m6etZ+kWU9ESL1Qy+lHEk9HqUOg25xQb5gPDrIP3TOMSsUU= =mrfT -----END PGP SIGNATURE-----

No intent? It wouldn't be terribly hard, they could just RNG over the register afterwards or run a 1/1 to nullify any data left therein. The latter would require control lines to be in place, the latter would just mean extending the microcode instruction. That said I could understand the want to depricate zen1 support entirely, everyone upgraded when they could it was super super cheap to do so & there weren't really any enterprise users.

On Tue, Oct 3, 2023 at 3:54 PM Solar Designer <solar () openwall com> wrote: On Tue, Oct 03, 2023 at 03:02:41PM -0700, Jean Luc Picard wrote: Hi, just dropping in, is this the kind of thing to where the userspace & kernel layers need mitigation until there's microcode mitigation? In general, kind of yes - it could have been that kind of thing.

More specifically, no - in this case, only kernel and hypervisor and system configuration (disable SMT) mitigations are expected. No userspace mitigations, other than maybe specific algorithms avoiding integer divide operations based on secrets where they can. While AMD maybe could fix this in microcode (or maybe not, or maybe with unacceptable performance penalty), they expressed no plans to do so. On Tue, Oct 3, 2023 at 2:46???PM Jeremy Stanley <fungi () yuggoth org> wrote: 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. Andrew, sending a second message like Jeremy suggests works best. Bcc currently isn't expected to work at all. Thank you!

BTW, in this case I think the problem was actually for Xen's lists more than for oss-security - you included xen-announce among the CC'ed lists, and this means e.g. Demi Marie's reply was attempted to be posted to there, while certainly not being a valid Xen announcement. However, I guess external messages to the announcement list are very easy to reject on your side. It's not so easy for us on oss-security because we've setup some senders to bypass moderation, yet those people participate in threads on other lists that might just happen to be CC'ed in here and they might not notice that the rest of the sub-thread is moderated-out.

I'm not too concerned about this issue with Xen announcements in particular - things have worked pretty well with these so far.

Alexander

On Tue, Sep 26, 2023 at 06:16:22PM +0100, Andrew Cooper wrote: On 26/09/2023 5:09 pm, Solar Designer wrote: Is the original paper public? https://www.usenix.org/system/files/usenixsecurity23-hofmann.pdf

Section 8.2.1 for the results specific to divides. Thank you! 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. Of course, the worst case is much worse like that. If I'm reading this right, the timings I found above are for dividing 0 by something, so should apply to Linux's 0/1. Xen does 1/1 instead:

https://github.com/xen-project/xen/commit/d7b78041dc819efde0350f27754a61cb01a93496

Luckily, the timings for 1/1 look just as good:

$ grep -r ': DIV . 1/1' InstLatx64/AuthenticAMD/Zen.txt InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 415 X86 : DIV r8 1/1 L: 4.14ns= 13.0c T: 4.14ns= 13.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 416 X86 : DIV r8 1/1 ax upd L: 4.14ns= 13.0c T: 4.14ns= 13.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 427 X86 : DIV r16 1/1 L: 4.45ns= 14.0c T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 428 X86 : DIV r16 1/1 ax upd L: 4.45ns= 14.0c T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 429 X86 : DIV r16 1/1 ax/dx upd L: 4.45ns= 14.0c T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 441 X86 : DIV r32 1/1 L: 4.45ns= 14.0c T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 442 X86 : DIV r32 1/1 eax upd L: 4.45ns= 14.0c T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 443 X86 : DIV r32 1/1 eax/edx upd L: 4.45ns= 14.0c T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 455 AMD64 : DIV r64 1/1 L: 4.45ns= 14.0c T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 456 AMD64 : DIV r64 1/1 rax upd L: 4.45ns= 14.0c T: 4.45ns= 14.00c InstLatx64/AuthenticAMD/AuthenticAMD0800F00K17ZenInstLatX64.txt:Inst 457 AMD64 : DIV r64 1/1 rax/rdx upd L: 4.45ns= 14.0c T: 4.45ns= 14.00c 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. Makes sense. 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. Right. Great not to clobber RDX.

However, this may be another reason to actually look into whether the remainder also leaked, and whether the byte-sized form prevents that leak despite of it not touching the architectural register where the remainder would be stored by a preceding larger DIV. I expect that we're fine here - it's the divider unit's internal register and not the architectural register that should matter - but worth making sure. It could also theoretically be e.g. some buffer registers in the middle, where the byte-sized form wouldn't overwrite the full contents.

Alexander

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.

Alexander

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

Xen Security Advisory CVE-2022-40982 / XSA-435

x86/Intel: Gather Data Sampling

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

A researcher has discovered Gather Data Sampling, a transient execution side-channel whereby the AVX GATHER instructions can forward the content of stale vector registers to dependent instructions.

The physical register file is a structure competitively shared between sibling threads. Therefore an attacker can infer data from the sibling thread, or from a more privileged context.

For more details, see: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html

IMPACT ======

An attacker can infer data from different contexts on the same core. Examples of such data includes key material, cipher and plaintext from the AES-NI instructions, or the contents of REP-MOVS instructions, commonly used to implement memcpy().

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

Systems running all versions of Xen are affected.

See the Intel documentation for a list of affected processors.

CPUs from other hardware vendors are not believed to be affected.

MITIGATION ==========

This issue can be mitigated by disabling AVX, either by booting Xen with cpuid=no-avx on the command line, or by specifying cpuid="host:avx=0" in the vm.cfg file of all untrusted VMs. However, this may come with a significant performance impact on the system and is not recommended for anyone able to deploy the microcode and patch described below.

RESOLUTION ==========

Intel are producing microcode updates to address the issue for most affected CPUs. Consult your dom0 OS vendor. This microcode is effective when late-loaded, which can be performed on a live system without reboot.

Without microcode, disabling AVX is the only mitigation. This is implemented by the patches to Xen on hardware believed to be vulnerable.

In addition, to indicate safety to guest kernels, Xen needs to synthesise new bits for guests to see, which depends on MSRARCHCAPS being visible to guests. The work to support MSRARCHCAPS is extensive and has been going on in public in earnest since March. The backports to security trees are more-extensive still.

Therefore, we have decided to produce new releases on all stable trees. Please find fixes in the respective branches under the following release tags:

RELEASE-4.17.2 RELEASE-4.16.5 RELEASE-4.15.5 RELEASE-4.14.6

Other release activities (tarballs, announcements, etc) will happen in due course. -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmTSZQcMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZoMQH/RAjt/wZHCg/aFunhbiAbdzWmJo36Cz6KL+R2G+v sBiPMsBvZxSikl6yeYAADgEUFKqNWQhLCAl6oaqgPbtDhFOxeZ72DRhgwZIx2KNL 85ECXk3rFhipiai6oHHbOemjPglXsyz+B5+NE64gOjpjdms9cfvfWnMnSQRF+NKa vbpEeP+KIK1EcmKOp/xfzjjgEzg7VmJ8jnct0A77sUQYi3Ll1+ENLEcqDElP+Qob wmM6QYkz78q/xO+R+bT+NNJ33q6JXQdixXa3ddiWrcvL/A3SveqtQh78u9daKmFM aaivBTgJSWk0348aelEF8UjLNKx8rVRc4Dk2elioiE1PCe8= =05gz -----END PGP SIGNATURE-----

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

Xen Security Advisory XSA-433

x86/AMD: Zenbleed

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

Researchers at Google have discovered Zenbleed, a hardware bug causing corruption of the vector registers.

When a VZEROUPPER instruction is discarded as part of a bad transient execution path, its effect on internal tracking are not unwound correctly. This manifests as the wrong micro-architectural state becoming architectural, and corrupting the vector registers.

Note: While this malfunction is related to speculative execution, this is not a speculative sidechannel vulnerability.

The corruption is not random. It happens to be stale values from the physical vector register file, a structure competitively shared between sibling threads. Therefore, an attacker can directly access data from the sibling thread, or from a more privileged context.

For more details, see: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html https://github.com/google/security-research/security/advisories/GHSA-v6wh-rxpg-cmm8

IMPACT ======

With very low probability, corruption of the vector registers can occur. This data corruption causes mis-calculations in subsequent logic.

An attacker can exploit this bug to read data from different contexts on the same core. Examples of such data includes key material, cypher and plaintext from the AES-NI instructions, or the contents of REP-MOVS instructions, commonly used to implement memcpy().

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

Systems running all versions of Xen are affected.

This bug is specific to the AMD Zen2 microarchitecture. AMD do not believe that other microarchitectures are affected.

MITIGATION ==========

This issue can be mitigated by disabling AVX, either by booting Xen with cpuid=no-avx on the command line, or by specifying cpuid="host:avx=0" in the vm.cfg file of all untrusted VMs. However, this will come with a significant impact on the system and is not recommended for anyone able to deploy the microcode or patch described below.

RESOLUTION ==========

AMD are producing microcode updates to address the bug. Consult your dom0 OS vendor. This microcode is effective when late-loaded, which can be performed on a live system without reboot.

In cases where microcode is not available, the appropriate attached patch updates Xen to use a control register to avoid the 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.

xsa433.patch xen-unstable xsa433-4.17.patch Xen 4.17.x xsa433-4.16.patch Xen 4.16.x xsa433-4.15.patch Xen 4.15.x xsa433-4.14.patch Xen 4.14.x

$ sha256sum xsa433 a9331733b63e3e566f1436a48e9bd9e8b86eb48da6a8ced72ff4affb7859e027 xsa433.patch 6f1db2a2078b0152631f819f8ddee21720dabe185ec49dc9806d4a9d3478adfd xsa433-4.14.patch ca3a92605195307ae9b6ff87240beb52a097c125a760c919d7b9a0aff6e557c0 xsa433-4.15.patch e5e94b3de68842a1c8d222802fb204d64acd118e3293c8e909dfaf3ada23d912 xsa433-4.16.patch 41d12104869b7e8307cd93af1af12b4fd75a669aeff15d31b234dc72981ae407 xsa433-4.17.patch $

NOTE CONCERNING TIMELINE ========================

This issue is subject to coordinated disclosure on August 8th. The discoverer chose to publish details ahead of this timeline. -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmS+oDEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ4JkIAMOW9i78luUOEgggrQDp97T1CMAhew+3v+r2ZPMl z7a6ATRU3oW7yeepYEP/1mrRFi2E09zrj0rDLvLVrYrhqeDGVIL+ZfI480508/5Y ubRYZC13rA3jDMDu9r+oBIzObumecRAVj54j5BQmuKyXDqkDMGfbVShpMMvARvhE wqlBXNFB1Z+ARlDrDZZo6sKhfUqHS4Fo8iilWthKxY9Eb0cxxA1PazMJz5OOaqe6 6Y3hHrSN4dq3DseAhYGgtw+BOTa/XlgAzkdlJM0DvooS22HFuHqwB7dckrtpCMlC 6I3P3p0GfsnG8U99lxYWzuEbtAKwSsFf/da2S8A4rel0aOE= =xmQd -----END PGP SIGNATURE-----

Description of problem:

The recent fix to validate the frontend's frame buffer description neglected to limit the frame buffer size correctly. This lets a malicious frontend make the backend attempt to map an arbitrary amount of guest memory, which could be useful for a denial of service attack against dom0.

Proposed upstream patch:

http://xenbits.xensource.com/xen-unstable.hg?rev/9044705960cb30cec385bdca7305bcf7db096721