From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fRPe3-0003Ln-KY for speck@linutronix.de; Sat, 09 Jun 2018 00:14:08 +0200 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8636D407048F for ; Fri, 8 Jun 2018 22:14:00 +0000 (UTC) Received: from treble (ovpn-120-53.rdu2.redhat.com [10.10.120.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 551AA2166BB2 for ; Fri, 8 Jun 2018 22:14:00 +0000 (UTC) Date: Fri, 8 Jun 2018 17:13:58 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: [PATCH 1/2] L1TF KVM 1 Message-ID: <20180608221358.fc2m4ccndpe52zji@treble> References: <20180529194214.2600-1-pbonzini@redhat.com> <20180529194240.5654A61109@crypto-ml.lab.linutronix.de> <20180608174904.yftmnngfkj6f3rrr@treble> <20180608204907.GC7385@char.us.oracle.com> MIME-Version: 1.0 In-Reply-To: <20180608204907.GC7385@char.us.oracle.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Jun 08, 2018 at 04:49:07PM -0400, speck for Konrad Rzeszutek Wilk wrote: > 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? Right, just something as simple as setting a global variable (which lives in bugs.c) would probably be good enough. -- Josh