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 1fROJw-0002Zt-OC for speck@linutronix.de; Fri, 08 Jun 2018 22:49:17 +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 w58KkIsQ100237 for ; Fri, 8 Jun 2018 20:49:09 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2jbvypevb2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 08 Jun 2018 20:49:09 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w58Kn8C9012026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 8 Jun 2018 20:49:08 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w58Kn87k029597 for ; Fri, 8 Jun 2018 20:49:08 GMT Date: Fri, 8 Jun 2018 16:49:07 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [PATCH 1/2] L1TF KVM 1 Message-ID: <20180608204907.GC7385@char.us.oracle.com> References: <20180529194214.2600-1-pbonzini@redhat.com> <20180529194240.5654A61109@crypto-ml.lab.linutronix.de> <20180608174904.yftmnngfkj6f3rrr@treble> MIME-Version: 1.0 In-Reply-To: <20180608174904.yftmnngfkj6f3rrr@treble> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Jun 08, 2018 at 12:49:04PM -0500, speck for Josh Poimboeuf wrote: > 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. > > > > 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). > > > > Signed-off-by: Paolo Bonzini > > I think we should report the L1 flushing mitigation value (i.e., 0, 1 or > 2) in the 'l1tf' vulnerabilities sysfs file. But this is KVM module, not the generic code (bugs.c). Or did you have in mind some sub-registration code so that the KVM module can register its state of mind with bugs.c reporting? Like 'L1D flush on VMENTER','IPI on VMEXIT', etc?