[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Xen Security Advisory 320 v2 (CVE-2020-0543) - Special Register Buffer speculative side channel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2020-0543 / XSA-320 version 2 Special Register Buffer speculative side channel UPDATES IN VERSION 2 ==================== Add a link to Intel's cross reference of affected hardware. Provide a suggested workaround for Ivy Bridge hardware, which is not receiving a microcode update. This includes a 3rd patch for each release. ISSUE DESCRIPTION ================= This issue is related to the MDS and TAA vulnerabilities. Please see https://xenbits.xen.org/xsa/advisory-297.html (MDS) and https://xenbits.xen.org/xsa/advisory-305.html (TAA) for details. Certain processor operations microarchitecturally need to read data from outside the physical core (e.g. to communicate with the random number generator). In some implementations, this operation is called a Special Register Read. In some implementations, data are staged in a single shared buffer, and a full cache line at a time is returned to the core which made the Special Register Read. On parts vulnerable to MFBDS or TAA, an attacker may be able to access stale data requested by other cores in the system. For more details, see: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00320.html https://software.intel.com/security-software-guidance/processors-affected-transient-execution-attack-mitigation-product-cpu-model IMPACT ====== An attacker, which could include a malicious untrusted user process on a trusted guest, or an untrusted guest, can sample the contents of certain off-core accesses by other cores in the system. This can include data whose use may depend on the secrecy of the value, such as data from the Random Number Generator (e.g. RDRAND/RDSEED instructions). VULNERABLE SYSTEMS ================== Systems running all versions of Xen are affected. Only x86 processors are vulnerable. ARM processors are not believed to be vulnerable. Only Intel based processors are affected. Processors from other manufacturers (e.g. AMD) are not believed to be vulnerable. Please consult the Intel Security Advisory for details on the affected processors. MITIGATION ========== Disabling RDRAND (and, where applicable, RDSEED) will avoid the vulnerability. It may have other adverse consequences, such as guests generating keys with weak random numbers, or guests hanging during boot waiting for entropy. A domain (guest, dom0, or service domain) which is runs with RDRAND disabled in CPUID, and whose software conforms to normal feature detection as specified in the Intel/AMD manuals, will not be vulnerable to snooping by other domains. But such a domain *can* still potentially snoop on any domains which are still using RDRAND. This mitigation is recommended to be applied globally, due to the practical complexity of auditing all software in a VM to confirm that there are no vulnerable uses of the RDRAND/RDSEED instructions. RDRAND and RDSEED can be disabled at the host level by booting Xen with `cpuid=no-rdrand,no-rdseed`, which will hide the feature from all domains including guests and dom0. Xen 4.12 and earlier require the appropriate patch 3 below for this mechanism to work. RDRAND and RDSEED can be disabled for guests with the following setting in the VM configuration file (xl.cfg): cpuid=["host:rdrand=0,rdseed=0]" (NB it would have to be merged into any existing cpuid= setting). Xen 4.9 and earlier require the appropriate patch 3 below for this mechanism to work. RESOLUTION ========== New microcode is being released on some affected parts to work around the vulnerability. It may be available via a firmware update (consult your hardware vendor), or available for OS loading (consult your dom0 OS vendor). For Ivy Bridge hardware, which is not receiving a microcode update, see MITIGATION, above. On Xen 4.13 and later, OS microcode can be loaded at runtime. See https://xenbits.xen.org/docs/latest/admin-guide/microcode-loading.html#runtime-microcode-loading for details on the xen-ucode utility. Loading the microcode, either at boot or at runtime, suffices to mitigate the issue, as protections are active by default. The mitigations do have an impact on latency of individual RDRAND/RDSEED instructions. The patches below are for Xen, and offer boot time information, defaults selection, opt-out controls, and uniform controls for hiding the RDRAND/RDSEED instructions. 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. xsa320/xsa320-?.patch xen-unstable xsa320/xsa320-4.13-?.patch Xen 4.13.x xsa320/xsa320-4.12-?.patch Xen 4.12.x xsa320/xsa320-4.11-?.patch Xen 4.11.x xsa320/xsa320-4.10-?.patch Xen 4.10.x xsa320/xsa320-4.9-?.patch Xen 4.9.x $ sha256sum xsa320*/* 84e4f66492042b08e69b0894ea7feb20c17c89a696cf95f05a8826fba4f26355 xsa320/xsa320-1.patch 5a3a06c72d0281fa1191ba18e39b836d2748400d9bf6a59dd45447850530c88b xsa320/xsa320-2.patch fd15c8a5098ce70af85c6cf1f69f1e6b51eabfda0a0bb780b27f47a8ae44e3a2 xsa320/xsa320-3.patch 759259ef88c980363d44e11d9c272f6a4a15918e5e6bcdfe971b1ce7ea160cd9 xsa320/xsa320-4.9-1.patch ebac2c011841c55c3c1e99d9e8afc53e56e54268d379ec8b904f6bfe6a1a5045 xsa320/xsa320-4.9-2.patch 3aeade2c9bb1fe77f6c076d531378d3971aa44cdb87996bda27565fa6e707bd2 xsa320/xsa320-4.9-3.patch 5c622c74358ab21cbd27484c649f26df0f08e89ec333c346415bc51e35ba26c1 xsa320/xsa320-4.10-1.patch f112e34a6a4564a043926fc255a15c7e319001bd023a97ae2947228024e1c306 xsa320/xsa320-4.10-2.patch 1ff6f34840ddb23b7f9bad5e2a1a5cf5246a55219ce7f686f2d80b3dc55e2960 xsa320/xsa320-4.10-3.patch f24b51292be0cb5de80c6eff0b26983629dd48cc39ae5a331e2e38e15a6cf712 xsa320/xsa320-4.11-1.patch 03579810eaf2e9eeb1a82de4b50ff5c4b01e60b30ccf7609c9e3378ef576d81e xsa320/xsa320-4.11-2.patch fa4bcb5422a43395bfe57b8e324b80e447b004eb24360b78343577de0f247067 xsa320/xsa320-4.11-3.patch 282537ffe2fd4332c0e061ddc537bea3e135a7bbd9253ec298becb49047323cf xsa320/xsa320-4.12-1.patch e4417429297354c233e8f5c261aff4888aae602f8c68897c09b16ea1aa44b1ca xsa320/xsa320-4.12-2.patch dd374e6c11c54c4077895132b8cc5771d3193df2febde643fcef94f973ee409e xsa320/xsa320-4.12-3.patch 611f2ab1a1c67e04767188d9803b6afd7d304e81a5b4f1eb1744d3e8a68ced66 xsa320/xsa320-4.13-1.patch cd1bc0071e72e2342ff4508ea3d937988694f4c03506b3afb3184f7d81aa1c86 xsa320/xsa320-4.13-2.patch 1fe0437059bac1fcc4be44ec3c9f9b53f4c5568c8f02c3f2aa2e452febe39cd1 xsa320/xsa320-4.13-3.patch $ NOTE REGARDING LACK OF EMBARGO ============================== Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl7iLP8MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZYSMIAISQRxbfSDYpTKAObAGn7Jhv4rGM4C0gYagFWKxb eLuhvWZN49uPuyIfsO8WfZxAQJTP2hEDNd4ncFYwS7JbD/F/RCsYFgiasw/aqCUX 9vEkRtrvD7XvIe0DWAjHUrvaFvnjI/vl03D3kxQw15eDPXU8pQMPrfva6W1PrQfv +b+aQHiawR6MPawCraK3kfCs1dTEnrkH+vL5h+nnEyB34ciTG+Z1g3Rhx7GMh6+7 tb9VLOPZMRvvCRii3pRBolcT0MmZAcakbBxCixMDo7bSEaw3G7Zro2RO9MvvsoFF r1Pa8IC8kVTWQTi8CYS46E1TvQ7yr86ERejaFQs0fk6vxhI= =N8eC -----END PGP SIGNATURE----- Attachment:
xsa320/xsa320-1.patch Attachment:
xsa320/xsa320-2.patch Attachment:
xsa320/xsa320-3.patch Attachment:
xsa320/xsa320-4.9-1.patch Attachment:
xsa320/xsa320-4.9-2.patch Attachment:
xsa320/xsa320-4.9-3.patch Attachment:
xsa320/xsa320-4.10-1.patch Attachment:
xsa320/xsa320-4.10-2.patch Attachment:
xsa320/xsa320-4.10-3.patch Attachment:
xsa320/xsa320-4.11-1.patch Attachment:
xsa320/xsa320-4.11-2.patch Attachment:
xsa320/xsa320-4.11-3.patch Attachment:
xsa320/xsa320-4.12-1.patch Attachment:
xsa320/xsa320-4.12-2.patch Attachment:
xsa320/xsa320-4.12-3.patch Attachment:
xsa320/xsa320-4.13-1.patch Attachment:
xsa320/xsa320-4.13-2.patch Attachment:
xsa320/xsa320-4.13-3.patch
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |