From patchwork Wed Feb 14 16:12:13 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Michael Roth X-Patchwork-Id: 873424 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3zhPvW5gZnz9t3F for ; Thu, 15 Feb 2018 03:27:35 +1100 (AEDT) Received: from localhost ([::1]:36926 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elzu9-0003DB-NF for incoming@patchwork.ozlabs.org; Wed, 14 Feb 2018 11:27:33 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elzgY-0007YC-TD for qemu-devel@nongnu.org; Wed, 14 Feb 2018 11:13:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1elzgU-0001xq-OU for qemu-devel@nongnu.org; Wed, 14 Feb 2018 11:13:30 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:59604) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1elzgU-0001wj-F8 for qemu-devel@nongnu.org; Wed, 14 Feb 2018 11:13:26 -0500 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1EGCNVr113812 for ; Wed, 14 Feb 2018 11:13:25 -0500 Received: from e15.ny.us.ibm.com (e15.ny.us.ibm.com [129.33.205.205]) by mx0a-001b2d01.pphosted.com with ESMTP id 2g4n6r9ph9-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 14 Feb 2018 11:13:24 -0500 Received: from localhost by e15.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 14 Feb 2018 11:13:23 -0500 Received: from b01cxnp23033.gho.pok.ibm.com (9.57.198.28) by e15.ny.us.ibm.com (146.89.104.202) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 14 Feb 2018 11:13:19 -0500 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w1EGDItH52494566; Wed, 14 Feb 2018 16:13:18 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B92EA112062; Wed, 14 Feb 2018 11:11:17 -0500 (EST) Received: from localhost (unknown [9.80.80.95]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP id 878EB112040; Wed, 14 Feb 2018 11:11:17 -0500 (EST) From: Michael Roth To: qemu-devel@nongnu.org Date: Wed, 14 Feb 2018 10:12:13 -0600 X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 X-TM-AS-GCONF: 00 x-cbid: 18021416-0036-0000-0000-000002BE0F6A X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008533; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000253; SDB=6.00989663; UDB=6.00502543; IPR=6.00769018; BA=6.00005830; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019552; XFM=3.00000015; UTC=2018-02-14 16:13:21 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18021416-0037-0000-0000-0000435520AB Message-Id: <20180214161213.7894-1-mdroth@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-14_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802140191 X-MIME-Autoconverted: from 8bit to quoted-printable by mx0a-001b2d01.pphosted.com id w1EGCNVr113812 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 148.163.156.1 Subject: [Qemu-devel] [qemu-web PATCH v2] Add a blog post documenting Spectre/Meltdown options for QEMU 2.11.1 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Thomas Huth , Eduardo Habkost , David Hildenbrand , Cornelia Huck , Bruce Rogers , Christian Borntraeger , Suraj Jitindar Singh , Paolo Bonzini , David Gibson Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" This blog entry is intended as a follow-up to the original entry in January regarding Spectre/Meltdown and the proposed changes to address them in the upcoming 2.11.1 release. This entry is meant to accompany the 2.11.1 release (planned for 2018-02-14) and document how to make use of the new options for various architectures. Cc: Eduardo Habkost Cc: Paolo Bonzini Cc: Peter Maydell Cc: Suraj Jitindar Singh Cc: David Gibson Cc: Christian Borntraeger Cc: Cornelia Huck Cc: Thomas Huth Cc: Bruce Rogers Cc: Daniel P. Berrangé Cc: David Hildenbrand Signed-off-by: Michael Roth --- v2: * s/by itself that/by itself for that/ (Bruce) * make example formats more consistent (Bruce) * clarify wording WRT to host-side security (Daniel, Paolo) * general wording/formatting fix-ups (Thomas) * s/options/feature bits/ (Cornelia) * clarify s390x CPU feature defaults (Thomas/Cornelia/Christian/David) * clarify s390x migration compatibility statement (Cornelia) Thank you for the review! .../2018-02-14-qemu-2-11-1-and-spectre-update.md | 190 +++++++++++++++++++++ 1 file changed, 190 insertions(+) create mode 100644 _posts/2018-02-14-qemu-2-11-1-and-spectre-update.md diff --git a/_posts/2018-02-14-qemu-2-11-1-and-spectre-update.md b/_posts/2018-02-14-qemu-2-11-1-and-spectre-update.md new file mode 100644 index 0000000..9ddf74f --- /dev/null +++ b/_posts/2018-02-14-qemu-2-11-1-and-spectre-update.md @@ -0,0 +1,190 @@ +--- +layout: post +title: "QEMU 2.11.1 and making use of Spectre/Meltdown mitigation for KVM guests" +date: 2018-02-14 10:35:44 -0600 +author: Michael Roth +categories: [meltdown, spectre, security, x86, ppc, s390, releases, 'qemu 2.11'] +--- + +A [previous post](https://www.qemu.org/2018/01/04/spectre/) detailed how +QEMU/KVM might be affected by Spectre/Meltdown attacks, and what the plan +was to mitigate them in QEMU 2.11.1 (and eventually QEMU 2.12). + +QEMU 2.11.1 is now available, and contains the aforementioned mitigation +functionality for x86 guests, along with additional mitigation functionality +for pseries and s390x guests (ARM guests do not currently require additional +QEMU patches). However, enabling this functionality requires additional +configuration beyond just updating QEMU, which we want to address with this +post. + +Please note that QEMU/KVM has at least the same requirements as other +unprivileged processes running on the host with regard to Spectre/Meltdown +mitigation. What is being addressed here is enabling a guest operating system +to enable the same (or similar) mitigations to protect itself from +unprivileged guest processes running under the guest operating system. Thus, +the patches/requirements listed here are specific to that goal and should not +be regarded as the full set of requirements to enable mitigations on the host +side (though in some cases there is some overlap between the two with regard +to required patches/etc). + +Also please note that this is a best-effort from the QEMU/KVM community, and +these mitigations rely on a mix of additional kernel/firmware/microcode +updates that are in some cases not yet available publicly, or may not yet be +implemented in some distros, so users are highly encouraged to consult with +their respective vendors/distros to confirm whether all the required +components are in place. We do our best to highlight the requirements here, +but this may not be an exhaustive list. + + +## Enabling mitigation features for x86 KVM guests + +For x86 guests there are 2 additional CPU flags associated with +Spectre/Meltdown mitigation: **spec-ctrl**, and **ibpb**: + +* spec-ctrl: exposes Indirect Branch Restricted Speculation (IBRS) +* ibpb: exposes Indirect Branch Prediction Barriers + +These flags expose additional functionality made available through new +microcode updates for certain Intel/AMD processors that can be used to +mitigate various attack vectors related to Spectre. (Meltdown mitigation +via KPTI does not require additional CPU functionality or microcode, and +does not require an updated QEMU, only the related guest/host kernel +patches). + +Utilizing this functionality requires guest/host kernel updates, as well +as microcode updates for Intel and recent AMD processors. The status of +these kernel patches upstream is still in flux, but most supported +distros have some form of the patches that is sufficient to make use +of the functionality. The current status/availability of microcode updates +depends on your CPU architecture/model. Please check with your +vendor/distro to confirm these prerequisites are available/installed. + +Generally, for Intel CPUs with updated microcode, **spec-ctrl** will +enable both IBRS and IBPB functionality. For AMD EPYC processors, +**ibpb** can be used to enable IBPB specifically, and is thought to +be sufficient by itself for that particular architecture. + +These flags can be set in a similar manner as other CPU flags, i.e.: + + qemu-system-x86_64 -cpu qemu64,+spec-ctrl,... ... + qemu-system-x86_64 -cpu IvyBridge,+spec-ctrl,... ... + qemu-system-x86_64 -cpu EPYC,+ibpb,... ... + etc... + +Additionally, for management stacks that lack support for setting +specific CPU flags, a set of new CPU types have been added which +enable the appropriate CPU flags automatically: + + qemu-system-x86_64 -cpu Nehalem-IBRS ... + qemu-system-x86_64 -cpu Westmere-IBRS ... + qemu-system-x86_64 -cpu SandyBridge-IBRS ... + qemu-system-x86_64 -cpu IvyBridge-IBRS ... + qemu-system-x86_64 -cpu Haswell-IBRS ... + qemu-system-x86_64 -cpu Haswell-noTSX-IBRS ... + qemu-system-x86_64 -cpu Broadwell-IBRS ... + qemu-system-x86_64 -cpu Broadwell-noTSX-IBRS ... + qemu-system-x86_64 -cpu Skylake-Client-IBRS ... + qemu-system-x86_64 -cpu Skylake-Server-IBRS ... + qemu-system-x86_64 -cpu EPYC-IBPB ... + +With these settings enabled, guests may still require additional +configuration to enable IBRS/IBPB, which may vary somewhat from one +distro to another. For RHEL guests, the following resource may be +useful: + +* https://access.redhat.com/articles/3311301 + +With regard to migration compatibility, **spec-ctrl**/**ibrs** (or the +corresponding CPU type) should be set the same on both source/target to +maintain compatibility. Thus, guests will need to be rebooted to make +use of the new features. + + +## Enabling mitigation features for pseries KVM guests + +For pseries guests there are 3 tri-state -machine options/capabilities +relating to Spectre/Meltdown mitigation: **cap-cfpc**, **cap-sbbc**, +**cap-ibs**, which each correspond to a set of host machine capabilities +advertised by the KVM kernel module in new/patched host kernels that can +be used to mitigate various aspects of Spectre/Meltdown: + +* cap-cfpc: Cache Flush on Privilege Change +* cap-sbbc: Speculation Barrier Bounds Checking +* cap-ibs: Indirect Branch Serialisation + +Each option can be set to one of "broken", "workaround", or "fixed", which +correspond, respectively, to instructing the guest whether the host is +vulnerable, has OS-level workarounds available, or has hardware/firmware +that does not require OS-level workarounds. Based on these options, QEMU +will perform checks to validate whether the specified settings are available +on the current host and pass these settings on to the guest kernel. At a +minimum, any setting other than "broken" will require a host kernel that has +some form of the following patches: + + commit 3214d01f139b7544e870fc0b7fcce8da13c1cb51 + KVM: PPC: Book3S: Provide information about hardware/firmware CVE workarounds + + commit 191eccb1580939fb0d47deb405b82a85b0379070 + powerpc/pseries: Add H_GET_CPU_CHARACTERISTICS flags & wrapper + +and whether a host will support "workaround" and "fixed" settings for each +option will depend on the hardware/firmware level of the host system. + +In turn, to make use of "workaround" or "fixed" settings for each option, +the guest kernel will require at least the following set of patches: + +* https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-January/167455.html + +These are available upstream and have been backported to a number of stable +kernels. Please check with your vendor/distro to confirm the required +hardware/firmware and guest kernel patches are available/installed. + +All three options, **cap-cfpc**, **cap-sbbc**, and **cap-ibs** default +to "broken" to maintain compatibility with previous versions of QEMU +and unpatched host kernels. To enable them you must start QEMU with the +desired mitigation strategy specified explicitly. For example: + + qemu-system-ppc64 ... \ + -machine pseries-2.11,cap-cfpc=workaround,cap-sbbc=workaround,cap-ibs=fixed + +With regard to migration compatibility, setting any of these features to a +value other than "broken" will require an identical setting for that option on +the source/destination guest. To enable these settings your guests will need to +be rebooted at some point. + + +## Enabling mitigation features for s390x KVM guests + +For s390x guests there are 2 CPU feature bits relating to Spectre/Meltdown: + +* bpb: Branch prediction blocking +* ppa15: PPA15 is installed + +**bpb** requires a host kernel patched with: + + commit 35b3fde6203b932b2b1a5b53b3d8808abc9c4f60 + KVM: s390: wire up bpb feature + +and both **bpb** and **ppa15** require a firmware with the appropriate support +level as well as guest kernel patches to enable the functionality within +guests. Please check with your distro/vendor to confirm. + +Both **bpb** and **ppa15** are enabled by default with newer/patched host +kernels, and can also be set manually. For example: + + qemu-system-s390x -M s390-ccw-virtio-2.11 ... \ + -cpu zEC12,bpb=on,ppa15=on + +Both **bpb** and **ppa15** are enabled by default when using "-cpu host" +and when the host kernels supports these facilities. For other CPU +models, the flags have to be set manually. For example: + + qemu-system-s390x -M s390-ccw-virtio-2.11 ... \ + -cpu zEC12,bpb=on,ppa15=on + +With regard to migration, enabling **bpb** or **ppa15** feature flags requires +that the source/target also those flags enabled. Since this is enabled by +default for '-cpu host' (when available on the host), you must ensure that +**bpb**=off,**ppa15**=off is used if you wish to maintain migration +compatibility with existing guests when using '-cpu host', or take steps to +reboot guests with **bpb**/**ppa15** enabled prior to migration.