From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 10 Jul 2018 18:00:39 -0000 Received: from userp2130.oracle.com ([156.151.31.86]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fcwwH-000395-Ly for speck@linutronix.de; Tue, 10 Jul 2018 20:00:38 +0200 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6AHwQqt044852 for ; Tue, 10 Jul 2018 18:00:31 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2k2p7633ad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 10 Jul 2018 18:00:30 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w6AI0TJR021831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 10 Jul 2018 18:00:30 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w6AI0Tol022299 for ; Tue, 10 Jul 2018 18:00:29 GMT Date: Tue, 10 Jul 2018 14:00:22 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [PATCH V2] Documentation: Add section about CPU vulnerabilities Message-ID: <20180710180022.GD20718@char.us.oracle.com> References: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: Thank you for doing the write up. I've some minor comments, please see below. > +Affected processors > +------------------- > + > +This vulnerability affects a wide range of Intel processors. The Perhaps spell out that AMD CPUs are _not_ affected? Say: This vulnerability affects a wide range of processors from Intel only (no AMD). > +vulnerability is not present on: > + > + - Older models, where the CPU family is < 6 > + > + - A range of ATOM processors (Cedarview, Cloverview, Lincroft, Penwell, > + Pineview, Slivermont, Airmont, Merrifield) > + > + - The Core Duo Yonah variants (2006 - 2008) > + > + - The XEON PHI family > + > + - Processors which have the ARCH_CAP_RDCL_NO bit set in the > + IA32_ARCH_CAPABILITIES MSR. If the bit is set the CPU is not affected > + by the Meltdown vulnerability either. These CPUs should become > + available by end of 2018. And here too in case the reader of the guide skip the beginning of the paragraph and are just enumerating? Say: - AMD CPUs - VIA ? ..snip.. > +Mitigation control for KVM - command line or module parameter > +------------------------------------------------------------- > + > +The KVM hypervisor mitigation mechanism, flushing the L1D cache when > +entering a guest, can be controlled from the kernel command line or when > +the KVM-Intel hypervisor is built as a module also with a module parameter. > + > +The option/parameter is "kvm-intel.vmentry_l1d_flush=". It takes the > +following arguments:: > + > + always: L1D cache flush on every VMENTER. > + > + cond: Flush L1D on VMENTER only when the code between VMEXIT and > + VMENTER can leak host memory which is considered > + interesting for an attacker. This still can leak host data > + which allows e.g. to determine the hosts address space layout. What is 'host data' vs 'host memory' ? > + > + never: Disables the mitigation > + > +The default is 'cond'. If 'l1tf=full' or 'l1tf=full,force' are given on the > +kernel command line, these take precedence. s/precedence/precedence over "kvm-intel.vmentry_l1d_flush="/ (just to be crystal clear?) > + > + > +Mitigation selection guide > +-------------------------- > + > +1. No virtualization in use > +^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > + The system is protected by the kernel unconditionally and no further > + action is required. > + > +2. Virtualization with trusted guests > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > + If the guest comes from a trusted source and the guest OS kernel is > + guaranteed to have the L1TF mitigations in place the system is fully > + protected against L1TF and no further action is required. > + > +3. Virtualization with untrusted guests > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +3.1. SMT not supported or disabled > +"""""""""""""""""""""""""""""""""" > + > + If SMT is not supported by the processor or disabled in the BIOS or by > + the kernel, it's only required to enforce L1D flushing on VMENTER. .. Which would require 'l1tf=full'. Should the guide spell it out? > + > +3.2. EPT not supported or disabled > +"""""""""""""""""""""""""""""""""" > + > + If EPT is not supported by the processor or disabled in the hypervisor, > + the system is fully protected. SMT can stay enabled and L1D flushing on > + VMENTER is not required. > + > +3.3. SMT and EPT supported and active > +""""""""""""""""""""""""""""""""""""" > + > + If SMT and EPT are supported and active then various degrees of > + mitigations can be employed: > + > + - L1D flushing on VMENTER: > + > + L1D flushing on VMENTER is the minimal protection requirement, but it > + is only potent in combination with other mitigation methods. > + > + - Guest confinement: > + > + Confinement of guests to a single or a group of physical cores which > + are not running any other processes, can reduce the attack surface > + significantly, but interrupts, soft interrupts and kernel threads can > + still expose valuable data to a potential attacker. > + > + - Interrupt isolation: > + > + Isolating the guest CPUs from interrupts can reduce the attack surface > + further, but still allows a malicious guest to explore a limited amount > + of host physical memory. This can at least be used to gain knowledge > + about the host address space layout. The interrupts which have a fixed > + affinity to the CPUs which run the untrusted guests can depending on > + the scenario still trigger soft interrupts and schedule kernel threads > + which might expose valuable information. > + > +The above three mitigation methods combined can provide protection to a > +certain degree, but the risk of the remaining attack surface has to be > +carefully analyzed. For full protection the following methods are > +available: > + > + - Disabling SMT: > + > + Disabling SMT and enforcing the L1D flushing provides the maximum > + amount of protection. This mitigation is not depending on any of the > + above mitigation methods. Perhaps say: Using 'l1tf=full' will achieve that. > + > + - Disabling EPT: > + > + Disabling EPT provides the maximum amount of protection as well. It is > + not depending on any of the above mitigation methods. SMT can stay > + enabled and L1D flushing is not required, but the performance impact is > + significant. Perhaps say: Using 'kvm-intel ept=0' will achieve that. ?