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 ; 11 Dec 2018 00:44:16 -0000 Received: from mail-lj1-x243.google.com ([2a00:1450:4864:20::243]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gWW9n-0000Jz-5y for speck@linutronix.de; Tue, 11 Dec 2018 01:44:15 +0100 Received: by mail-lj1-x243.google.com with SMTP id v15-v6so11346060ljh.13 for ; Mon, 10 Dec 2018 16:44:15 -0800 (PST) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id f8sm2384715lfb.2.2018.12.10.16.44.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Dec 2018 16:44:08 -0800 (PST) Received: by mail-lf1-f44.google.com with SMTP id p17so9470701lfh.4 for ; Mon, 10 Dec 2018 16:44:08 -0800 (PST) MIME-Version: 1.0 References: <0d6a3fbe4c511152a0f5350e62e9e09ec545f709.1544464266.git.ak@linux.intel.com> <20181211000303.GB16024@tassilo.jf.intel.com> In-Reply-To: <20181211000303.GB16024@tassilo.jf.intel.com> From: Linus Torvalds Date: Mon, 10 Dec 2018 16:43:56 -0800 Message-ID: Subject: [MODERATED] Re: [PATCH v2 3/8] MDSv2 5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Mon, Dec 10, 2018, 16:03 speck for Andi Kleen > > I don't think it's worth it because going into idle > isn't really that performance sensitive. Also if the > side effect is there its overhead really swamps any > call overhead. > It's exactly the "it's not even there" overhead we should look at. alternative already handles the noping, so I don't think we would > need a static branch, unless you want to toggle it at runtime? > The whole point is that you're adding a conditional branch and a call for something that does NOTHING! > "verw %[kernelds]" .. [kernelds] "m" (val) > > > > instead, letting gcc do the stack setup part. > > It has to be the memory form, only that has the necessary side effect > in the microcode. > That's exactly what the "m" there does. kernel exit doesn't use the C code, it's custom assembler. Yes, and that custom assembler has that disgusting call to the SW version that the code then enables by default. It's encryption keys etc. too. But yes. > I think the encryption key case could easily have a "let's scrub cpu state" thing. It already does other strange things, like memset_safe() or whatever it is that forces a memset even if the compiler decides it's dead. FWIW from our tests so far the performance loss from the kernel exit > overhead > doesn't seem to be that bad. > I haven't seen any numbers, and whilei can believe it's true for the verw case if there is hw acceleration, I doubt the SW case isn't noticeable. Plus we've already seen that people have been way too eager to apply patches just because there is alleged security implications, without doing any kind of risk vs cost analysis. Linus >