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:44:48 -0000 Received: from mga05.intel.com ([192.55.52.43]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fZ34I-0001Op-O7 for speck@linutronix.de; Sat, 30 Jun 2018 01:44:47 +0200 Date: Fri, 29 Jun 2018 16:44:35 -0700 From: Andi Kleen Subject: [MODERATED] Re: [PATCH 1/1 v2] Linux patch #1 Message-ID: <20180629234435.GD17013@tassilo.jf.intel.com> References: <20180629164807.lxbjex6m64xyfhgc@treble> <20180629195427.sj2jl4oqgavdozhf@treble> <20180629220548.GB17013@tassilo.jf.intel.com> <20180629232143.GC17013@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: > What's wrong with having a global switch, that could be deployed across > the whole (for example) datacenter, that says "if the cpu has L1TF issue, > do whatever it takes to mitigate it, otherwise operate normally"? Most people who use it would lose a lot of performance for no gain at all. > "nosmt" doesn't let you do that, as you'd have to know what x86 system > exactly you're booting on. The conditional one seems like the natural way > to go. Right that's the point. L1TF virtualization mitigation should be only done after properly analyzing the situation, never blindly. It's like a lot of other security threats, like let's say if your data is properly encrypted on the wire or how you configure a firewall. You cannot just get security blindly, but need to make some decisions to have useful trade offs. -Andi