From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp2130.oracle.com ([141.146.126.79]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fOnEQ-0003X0-If for speck@linutronix.de; Fri, 01 Jun 2018 18:48:51 +0200 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w51Gew9P081470 for ; Fri, 1 Jun 2018 16:48:43 GMT Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2janje5n7k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 01 Jun 2018 16:48:43 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w51GmffP011021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 1 Jun 2018 16:48:42 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w51Gmfkf011352 for ; Fri, 1 Jun 2018 16:48:41 GMT Date: Fri, 1 Jun 2018 12:48:40 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [PATCH 1/2] L1TF KVM 1 Message-ID: <20180601164840.GT24373@char.us.oracle.com> References: <20180529194214.2600-1-pbonzini@redhat.com> <20180529194239.768D561107@crypto-ml.lab.linutronix.de> MIME-Version: 1.0 In-Reply-To: <20180529194239.768D561107@crypto-ml.lab.linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, May 29, 2018 at 09:42:13PM +0200, speck for Paolo Bonzini wrote: > From: Paolo Bonzini > Subject: [PATCH 1/2] kvm: x86: mitigation for L1 cache terminal fault vulnerabilities > > This patch adds two mitigation modes for CVE-2018-3620, aka L1 terminal > fault. The two modes are "vmexit_l1d_flush=1" and "vmexit_l1d_flush=2". > > "vmexit_l1d_flush=2" is simply doing an L1 cache flush on every vmexit. > "vmexit_l1d_flush=1" is trying to avoid so on vmexits that are "confined" > in the kind of code that they execute. The idea is based on Intel's > patches, but the final list of "confined" vmexits isn't quite. s/quite/quite fleshed out/ > > Notably, L1 cache flushes are performed on EPT violations (which are > basically KVM-level page faults), vmexits that involve the emulator, > and on every KVM_RUN invocation (so each userspace exit). However, > most vmexits are considered safe. I singled out the emulator because > it may be a good target for other speculative execution-based threats, > and the MMU because it can bring host page tables in the L1 cache. > > The mitigation does not in any way try to do anything about hyperthreading; > it is possible for a sibling thread to read data from the cache during a > vmexit, before the host completes the flush, or to read data from the cache > while a sibling runs. This part of the work is not ready yet. > > For now I'm leaving the default to "vmexit_l1d_flush=2", in case we need > to push out the patches in an emergency embargo break, but I don't think > it's the best setting. The cost is up to 2.5x more expensive vmexits > on Haswell processors, and 30% on Coffee Lake (for the latter, this is > independent of whether microcode or the generic flush code are used). > This looks very much like what Jun had. If this was based off Intel code would it make sense to give credit to him by saying something along: "Ideas and some code based off from Jun .." ?