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 ; 12 Dec 2018 17:58:07 -0000 Received: from mga04.intel.com ([192.55.52.120]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gX8lq-0005in-3t for speck@linutronix.de; Wed, 12 Dec 2018 18:58:06 +0100 Date: Wed, 12 Dec 2018 09:58:03 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v2 3/8] MDSv2 5 Message-ID: <20181212175803.GF25620@tassilo.jf.intel.com> References: <0d6a3fbe4c511152a0f5350e62e9e09ec545f709.1544464266.git.ak@linux.intel.com> <20181211000303.GB16024@tassilo.jf.intel.com> <20181211032503.GB25620@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Dec 12, 2018 at 03:02:23PM +0100, speck for Paolo Bonzini wrote: > On 11/12/18 04:25, speck for Andi Kleen wrote: > > Okay. > > > > We'll have to disable interrupts in that window, but that > > should be ok. > > > > I guess it could be also set in some skb_* functions to catch > > the network cases. > > > > Or maybe setting when calling into unaudited code in interrupts/timers? > > > > And the flag would allow a "paranoid" mode which sets > > it unconditionally. > > That sounds a lot like kvm_get_cpu_l1tf_flush_l1d and > kvm_clear_cpu_l1tf_flush_l1d. Maybe we can just add another bit in > irq_cpustat_t's kvm_cpu_l1tf_flush_l1d, which would be cleared on return > to userspace before doing the verw stuff. This is not only for KVM, but also for any user space exits, so TIF flags is the natural mechanism. Right now the clearing on entry is unconditional. I thought about using the L1TF mechanism for KVM to avoid the clear for fast exits. However there is one problem: if the guest is using the software sequence and the sequence gets interrupted by an exit, then the only way to make sure the clearing happened correctly in the guest is to let the hypervisor do it. That would require unconditional clearing on entry. Unless we can somehow prove that fast exits only happen when the guest does something actively with an instruction. The clear sequence will not do any instruction that should cause exits, other than exits that can happen always (like interrupts or EPT violations). So would need to make sure that such "can always happen exits" would not trigger the fast exit no flush case. I'm not sure that is true today -Andi