[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] Xen Security Advisory 429 v3 (CVE-2022-42331) - x86: speculative vulnerability in 32b
From: Xen.org security team <security () xen ! org>
Date: 2023-03-21 12:00:46
Message-ID: E1peafW-0000G3-UU () xenbits ! xenproject ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2022-42331 / XSA-429
version 3
x86: speculative vulnerability in 32bit SYSCALL path
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
Due to an oversight in the very original Spectre/Meltdown security work
(XSA-254), one entrypath performs its speculation-safety actions too
late.
In some configurations, there is an unprotected RET instruction which
can be attacked with a variety of speculative attacks.
IMPACT
======
An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.
VULNERABLE SYSTEMS
==================
Xen versions 4.5 through 4.17 are vulnerable. Older versions are not
vulnerable.
Only x86 CPUs are potentially vulnerable. CPUs of other architectures
are not vulnerable.
The problematic codepath is only reachable on x86 CPUs which follow
AMD's behaviour with respect to SYSCALL instructions from compatibility
mode segments. This means that AMD and Hygon CPUs are potentially
vulnerable, whereas Intel CPUs are not. Other vendors have not been
checked.
Only PV guests can leverage the vulnerability.
On Xen 4.16 and later, the vulnerability is only present if 32bit PV
guest support is compiled in - i.e. CONFIG_PV32=y. On Xen 4.15 and
older, all supported build configurations are vulnerable.
The vulnerability is only present when booting on hardware that supports
SMEP or SMAP (Supervisor Mode Execution/Access Prevention). This is
believed to be some Family 0x16 models, and all later CPUs.
MITIGATION
==========
Not running untrusted PV guests will avoid the issue.
CREDITS
=======
This issue was discovered by Andrew Cooper of XenServer.
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.
xsa429.patch xen-unstable - Xen 4.16
xsa429-4.15.patch Xen 4.15 - Xen 4.14
$ sha256sum xsa429*
2d7be90d917c475ab5217e657d2b44f5d8b107d9023dca034fcfb7feab07b2f0 xsa429.meta
36ed36dbfaad9e5df5fa87b9a3d9e9c531f476f97eeb2afe280aa238032a0540 xsa429.patch
7ac3d4182585e5d2d39231f10e7c0c9fcb972c82cf81cb884e95b628187de3a7 xsa429-4.15.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/4UyVfoK9kFAmQZlWMMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZil4H/2b1DkLLz4RQqAgvaB8+SBeVLPqoZ7QxGLl8QXWT
AMjFdy+M5T1OtbrMvEYCZNYhZnGOJgmVagERUvg/yZbPYx28NIHjG4+u90Ot6OId
AQPqdrJ0wjEzN/ppNpnu1ALofAGbjsnAypEouGPh12gh5fcpcLQdT0rvpl2ff5f6
Qi4ShtUXhBiduBQcJ0TSneSCf5s7cq1+sMenntenK5Nrsvg7gu51YR45FyKyXdZc
raonkGDny9kmDAjdKkywS2Au2763ph9nHbW5TbD17s65AKUDTupzk+QlFPhJLIP+
/gxDoUjKFiD/eY0AABWMAFGGvHFRNvdhTfUd6ImmWhqdEeE=
=HxUJ
-----END PGP SIGNATURE-----
["xsa429.meta" (application/octet-stream)]
["xsa429.patch" (application/octet-stream)]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/spec-ctrl: Defer CR4_PV32_RESTORE on the cstar_enter path
As stated (correctly) by the comment next to SPEC_CTRL_ENTRY_FROM_PV, between
the two hunks visible in the patch, RET's are not safe prior to this point.
CR4_PV32_RESTORE hides a CALL/RET pair in certain configurations (PV32
compiled in, SMEP or SMAP active), and the RET can be attacked with one of
several known speculative issues.
Furthermore, CR4_PV32_RESTORE also hides a reference to the cr4_pv32_mask
global variable, which is not safe when XPTI is active before restoring Xen's
full pagetables.
This crash has gone unnoticed because it is only AMD CPUs which permit the
SYSCALL instruction in compatibility mode, and these are not vulnerable to
Meltdown so don't activate XPTI by default.
This is XSA-429 / CVE-2022-42331
Fixes: 5e7962901131 ("x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point")
Fixes: 5784de3e2067 ("x86: Meltdown band-aid against malicious 64-bit PV guests")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index ae012851819a..7675a59ff057 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -288,7 +288,6 @@ ENTRY(cstar_enter)
ALTERNATIVE "", "setssbsy", X86_FEATURE_XEN_SHSTK
#endif
push %rax /* Guest %rsp */
- CR4_PV32_RESTORE
movq 8(%rsp), %rax /* Restore guest %rax. */
movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat handled lower. */
pushq %r11
@@ -312,6 +311,8 @@ ENTRY(cstar_enter)
.Lcstar_cr3_okay:
sti
+ CR4_PV32_RESTORE
+
movq STACK_CPUINFO_FIELD(current_vcpu)(%rbx), %rbx
#ifdef CONFIG_PV32
["xsa429-4.15.patch" (application/octet-stream)]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/spec-ctrl: Defer CR4_PV32_RESTORE on the cstar_enter path
As stated (correctly) by the comment next to SPEC_CTRL_ENTRY_FROM_PV, between
the two hunks visible in the patch, RET's are not safe prior to this point.
CR4_PV32_RESTORE hides a CALL/RET pair in certain configurations (PV32
compiled in, SMEP or SMAP active), and the RET can be attacked with one of
several known speculative issues.
Furthermore, CR4_PV32_RESTORE also hides a reference to the cr4_pv32_mask
global variable, which is not safe when XPTI is active before restoring Xen's
full pagetables.
This crash has gone unnoticed because it is only AMD CPUs which permit the
SYSCALL instruction in compatibility mode, and these are not vulnerable to
Meltdown so don't activate XPTI by default.
This is XSA-429 / CVE-2022-42331
Fixes: 5e7962901131 ("x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point")
Fixes: 5784de3e2067 ("x86: Meltdown band-aid against malicious 64-bit PV guests")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index 5c999271e617..09a86768ac02 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -206,7 +206,6 @@ ENTRY(cstar_enter)
ALTERNATIVE "", "setssbsy", X86_FEATURE_XEN_SHSTK
#endif
push %rax /* Guest %rsp */
- CR4_PV32_RESTORE
movq 8(%rsp), %rax /* Restore guest %rax. */
movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat handled lower. */
pushq %r11
@@ -230,6 +229,8 @@ ENTRY(cstar_enter)
.Lcstar_cr3_okay:
sti
+ CR4_PV32_RESTORE
+
movq STACK_CPUINFO_FIELD(current_vcpu)(%rbx), %rbx
movq VCPU_domain(%rbx),%rcx
cmpb $0,DOMAIN_is_32bit_pv(%rcx)
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic