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 ; 29 Jun 2018 23:21:49 -0000 Received: from mga07.intel.com ([134.134.136.100]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fZ2i3-00015F-4E for speck@linutronix.de; Sat, 30 Jun 2018 01:21:48 +0200 Date: Fri, 29 Jun 2018 16:21:43 -0700 From: Andi Kleen Subject: [MODERATED] Re: [PATCH 1/1 v2] Linux patch #1 Message-ID: <20180629232143.GC17013@tassilo.jf.intel.com> References: <20180629164807.lxbjex6m64xyfhgc@treble> <20180629195427.sj2jl4oqgavdozhf@treble> <20180629220548.GB17013@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: > If I put myself in a shoes of a hypothetical admin, that basically means > that we'd have to have: > > - lt1tf=full (which currently means nosmt+pteinv, and once the > virtualization bits are merged it'll extend its meaning to whatever the > particular hypervisor considers full mitigation) I don't see any point in this. We should just have a nosmt option, but only recommend it after presenting the proper decision tree and when KVM is actually started. > > - l1tf=off (mitigations (maybe including PTEINV, but it doesn't make a > big difference really) is turned off, and hypervisors *don't* warn ever) This is pointless. The workaround is basically free and there is not reason to not use it. > > - l1tf=novirt (only PTEINV is turned on and hypervisors *do* warn when > they start VM and HT is on) > > Sounds acceptable? I think we shouldn't have l1tf= options at all. They're the wrong use model for this vulnerability. Just nosmt and proper warnings in KVM with documentation. Just because something was useful for spectre doesn't mean we need it here too. -Andi