Bug 1951722 (CVE-2021-28689)

Summary: CVE-2021-28689 xen: Speculative vulnerabilities with bare (non-shim) 32-bit PV guests (XSA-370)
Product: [Other] Security Response Reporter: Pedro Sampaio <psampaio>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: jforbes, m.a.young, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in Xen. Indirect Branch Restricted Speculation (IBRS) does not architecturally protect ring 0 from predictions learnt in ring 1. A malicious 32-bit PV guest could use this flaw to mount a Spectre v2 attack against Xen by conducting targeted cache side-channel attacks. The highest threat from this vulnerability is to data confidentiality.
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-04 20:33:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1956800    
Bug Blocks: 1951723    

Description Pedro Sampaio 2021-04-20 19:38:43 UTC
Xen Security Advisory CVE-2021-28689 / XSA-370

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

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.

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 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.org (or to
security) as soon as possible after the embargo lifts.

xsa370/*.patch         Xen unstable

$ sha256sum xsa370* xsa370*/*
ffb6e1be6a849b8e6930386d70817f53970f3d71a0a89980565c87070e85a7e2  xsa370.meta
1ff05633538ddfc38b2735ce721b8875557c433ffeda0c7f70481b4e7b191c4c  xsa370/0001-SUPPORT.md-Document-speculative-attacks-status-of-no.patch
a6ac6c20e04ddcc8817d3f432b86232ee8c138a9eb696be52e14cf968917522e  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

Comment 1 Mauro Matteo Cascella 2021-04-30 10:01:49 UTC
External References:

http://xenbits.xen.org/xsa/advisory-370.html

Comment 2 Mauro Matteo Cascella 2021-04-30 10:13:02 UTC
Acknowledgments:

Name: the Xen project

Comment 3 Mauro Matteo Cascella 2021-05-04 12:39:59 UTC
Created xen tracking bugs for this issue:

Affects: fedora-all [bug 1956800]

Comment 4 Mauro Matteo Cascella 2021-05-04 12:56:40 UTC
According to the upstream advisory (comment 1) there is no resolution available for this flaw, and none is ever expected. The patches provided only update the security support statement. For more information, please refer to the RESOLUTION section in the advisory.

Comment 5 Mauro Matteo Cascella 2021-05-04 13:14:42 UTC
Note that this flaw only affects 32-bit un-shimmed x86 PV guests (i.e., fully paravirtualized guests). All other Xen modes that leverage hardware assisted virtualization (e.g., HVM) are not affected by this flaw. 64-bit systems are not affected, either.

Comment 6 Product Security DevOps Team 2021-05-04 20:33:53 UTC
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.