Xen Security Advisory 370 v2 (CVE-2021-28689) - x86: Speculative vulnerabilities with bare (non-shim) 32-bit PV guests

Xen Security Advisory 370 v2 (CVE-2021-28689) - x86: Speculative vulnerabilities with bare (non-shim) 32-bit PV guests

[Xen.org security team]

[-- Attachment #1: Type: text/plain, Size: 6667 bytes --]

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

            Xen Security Advisory CVE-2021-28689 / XSA-370
                               version 2

   x86: Speculative vulnerabilities with bare (non-shim) 32-bit PV guests

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

Note that the patch is docs-only and the affected version ranges, in the
files summary of the Resolution section.

Public release.

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

32-bit x86 PV guest kernels run in ring 1.  At the time when Xen was
developed, this area of the i386 architecture was rarely used, which is why
Xen was able to use it to implement paravirtualisation, Xen's novel
approach to virtualization.  In AMD64, Xen had to use a different
implementation approach, so Xen does not use ring 1 to support 64-bit
guests.  With the focus now being on 64-bit systems, and the availability
of explicit hardware support for virtualization, fixing speculation issues
in ring 1 is not a priority for processor companies.

Indirect Branch Restricted Speculation (IBRS) is an architectural x86
extension put together to combat speculative execution sidechannel attacks,
including Spectre v2.  It was retrofitted in microcode to existing CPUs.

For more details on Spectre v2, see:
  http://xenbits.xen.org/xsa/advisory-254.html

However, IBRS does not architecturally protect ring 0 from predictions
learnt in ring 1.

For more details, see:
  https://software.intel.com/security-software-guidance/deep-dives/deep-dive-indirect-branch-restricted-speculation

Similar situations may exist with other mitigations for other kinds of
speculative execution attacks.  The situation is quite likely to be similar
for speculative execution attacks which have yet to be discovered,
disclosed, or mitigated.

IMPACT
======

A malicious 32-bit guest kernel may be able to mount a Spectre v2 attack
against Xen, despite the presence hardware protections being active.

It therefore might be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.

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

Systems running all versions of Xen are affected.

Only x86 systems are vulnerable, and only CPUs which are potentially
vulnerable to Spectre v2.  Consult your hardware manufacturer.

The vulnerability can only be exploited by 32-bit PV guests which are not
run in PV-Shim.

MITIGATION
==========

Running 32-bit PV guests under PV-Shim avoids the vulnerability when Spectre v2
protections are otherwise enabled on the system.

PV shim is available and fully security-supported in all
security-supported versions of Xen.  Using shim is the recommended
configuration.

Not running 32-bit PV guests avoids the vulnerability.

CREDITS
=======

This issue was discovered by Jann Horn of Google Project Zero.

RESOLUTION
==========

There is no resolution available, and none is ever expected.

The patches provided only update the security support statement.

The first patch is an unavoidable consequence of the discussions
above; the support status described is in effect immediately.

The security team does not consider the support status listed in patch
1 to be particularly useful; however, we do not feel we have the
authority to completely de-support non-shim 32-bit PV guests without
community consultation.

The second patch is the long-term support status the security team
proposes to the community. It will not become effective until three
weeks after the XSA-370 embargo lifts, and only if there are no
objections raised before that point.

If you need security support for un-shimmed 32-bit PV guests, please
make your voice heard on xen-devel@lists.xenproject.org (or to
security@xenproject.org) as soon as possible after the embargo lifts.

xsa370/*.patch         Xen unstable (docs only)
<no fix available>     Xen (all versions)

$ sha256sum xsa370* xsa370*/*
ffb6e1be6a849b8e6930386d70817f53970f3d71a0a89980565c87070e85a7e2  xsa370.meta
45c11df550f1900663a388106d6625e84fa280881e613825c830b1984f87b3a9  xsa370/0001-SUPPORT.md-Document-speculative-attacks-status-of-no.patch
48dfe434bcdf4f08b623b639079fd1c9f9b1939b279200550dbae7736340cb53  xsa370/0002-SUPPORT.md-Un-shimmed-32-bit-PV-guests-are-no-longer.patch
$

BARE 32 BIT PV SECURITY SUPPORT STATUS
======================================

This advisory discloses only a (very serious) information disclosure
vulnerability exploitable by bare 32 bit PV guests, using speculative
execution.

We are considering further entirely withdrawing security support for
configurations with non-shim 32 bit PV guests.  Any such decision,
including the precise scope of the (de)support, will be made following
public community discussion.

The result of that public process will be a patch to the security support
statement, backported (as applicable) to the relevant trees.

NOTE REGARDING EMBARGO
======================

In principle, the fact that the new CPU facilities are not capable of
protecting ring 0 Xen from a ring 1 PV guest, might be gleaned from
the hardware vendor documentation.

Howver, in practice this docuemntation is so difficult to find and
interpret that the implications discussed in this advisory are not
recognised widely, if at all.

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/4UyVfoK9kFAmCRH6YMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZNZIIAJiJsQvTRMfiBJ5+Yg4gyT7/T4vVkLZ4+j8FBlXL
1+SnIcOu5wgU0tmOADl58us9nZVZfo6X5xV4A+oJwrYvunI/1oGn27ylr3c0FYUH
PLSa8bGIw3BeeAGEpADL3rPIQtTeiokpGlkRSNaAz1N8kKypcY+4Ds4Pjtgz3Gd4
gk2y7U2wReV7OItk7Sp1lstyBdda1qClXedKJa+dENSzsf/6/o9Nad8sgCosMj+k
dx65CNgUWC2JRsMq+4fMTwhE2CtIh9IL4ylv7RyqI/ICW8UTMS2XOnALyjVIu1bI
96HCYrSCNclebmHI1385PV3CXUk6Goue0EDk3FxRTaBv7SM=
=YLXZ
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa370.meta --]
[-- Type: application/octet-stream, Size: 339 bytes --]

{
  "XSA": 370,
  "SupportedVersions": [
    "master"
  ],
  "Trees": [
    "xen"
  ],
  "Recipes": {
    "master": {
      "Recipes": {
        "xen": {
          "StableRef": "4834936549f788378918da8e9bc97df7dd3ee16d",
          "Prereqs": [],
          "Patches": [
            "xsa370/*.patch"
          ]
        }
      }
    }
  }
}

[-- Attachment #3: xsa370/0001-SUPPORT.md-Document-speculative-attacks-status-of-no.patch --]
[-- Type: application/octet-stream, Size: 1798 bytes --]

From 4e37e21f6e71752fb69c27ab9f1417a5d19ebedb Mon Sep 17 00:00:00 2001
From: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 9 Mar 2021 15:00:47 +0000
Subject: [PATCH 1/2] SUPPORT.md: Document speculative attacks status of
 non-shim 32-bit PV

This documents, but does not fix, XSA-370.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---

NB that the security team does not consider the security support
status of un-shimmed 32-bit PV guests in this patch to be particularly
useful. However, we do not consider ourselves to have the authority to decide
to completely de-support 32-bit PV guests without community consultation.

The support status in this patch should therefore be considered
transitional.  A permanent support status is proposed in a subsequent
patch in this series.

v2:
- Fix double 'be'
- Don't mention user -> kernel attacks, which have nothing to do with Xen
---
 SUPPORT.md | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 7db4568f1a..6dcd93e22f 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -84,7 +84,16 @@ Traditional Xen PV guest
 
 No hardware requirements
 
-    Status: Supported
+    Status, x86_64: Supported
+    Status, x86_32, shim: Supported
+    Status, x86_32, without shim: Supported, with caveats
+
+Due to architectural limitations,
+32-bit PV guests must be assumed to be able to read arbitrary host memory
+using speculative execution attacks.
+Advisories will continue to be issued
+for new vulnerabilities related to un-shimmed 32-bit PV guests
+enabling denial-of-service attacks or privilege escalation attacks.
 
 ### x86/HVM
 
-- 
2.30.2


[-- Attachment #4: xsa370/0002-SUPPORT.md-Un-shimmed-32-bit-PV-guests-are-no-longer.patch --]
[-- Type: application/octet-stream, Size: 2390 bytes --]

From: George Dunlap <george.dunlap@citrix.com>
Subject: SUPPORT.md: Un-shimmed 32-bit PV guests are no longer supported

The support status of 32-bit guests doesn't seem particularly useful.

With it changed to fully unsupported outside of PV-shim, adjust the PV32
Kconfig default accordingly.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---

NB this patch should be considered a proposal to the community.  It
will not become effective until three weeks after the XSA-370 embargo
lifts, and only if there are no objections raised before that point.

TBD: Should we also default opt_pv32 to false when not running in shim
     mode?

The (forward) dependency on PV_SHIM isn't very useful especially when
configuring from scratch - we may want to re-order items down the road,
such that the prompt for PV_SHIM occurs ahead of that for PV32. Yet then
this conflicts with PV_SHIM also depending on GUEST.

v3:
- Add Kconfig adjustment.

v2:
- Port over changes in patch 1

--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -86,14 +86,7 @@ No hardware requirements
 
     Status, x86_64: Supported
     Status, x86_32, shim: Supported
-    Status, x86_32, without shim: Supported, with caveats
-
-Due to architectural limitations,
-32-bit PV guests must be assumed to be able to read arbitrary host memory
-using speculative execution attacks.
-Advisories will continue to be issued
-for new vulnerabilities related to un-shimmed 32-bit PV guests
-enabling denial-of-service attacks or privilege escalation attacks.
+    Status, x86_32, without shim: Supported, not security supported
 
 ### x86/HVM
 
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -56,7 +56,7 @@ config PV
 config PV32
 	bool "Support for 32bit PV guests"
 	depends on PV
-	default y
+	default PV_SHIM
 	---help---
 	  The 32bit PV ABI uses Ring1, an area of the x86 architecture which
 	  was deprecated and mostly removed in the AMD64 spec.  As a result,
@@ -67,7 +67,10 @@ config PV32
 	  reduction, or performance reasons.  Backwards compatibility can be
 	  provided via the PV Shim mechanism.
 
-	  If unsure, say Y.
+	  Note that outside of PV Shim, 32-bit PV guests are not security
+	  supported anymore.
+
+	  If unsure, use the default setting.
 
 config PV_LINEAR_PT
        bool "Support for PV linear pagetables"