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 02:10:30 -0000 Received: from mga18.intel.com ([134.134.136.126]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gWXVC-0001q2-7m for speck@linutronix.de; Tue, 11 Dec 2018 03:10:28 +0100 Date: Mon, 10 Dec 2018 18:10:20 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v2 3/8] MDSv2 5 Message-ID: <20181211021020.GF16024@tassilo.jf.intel.com> References: <0d6a3fbe4c511152a0f5350e62e9e09ec545f709.1544464266.git.ak@linux.intel.com> <20181211000303.GB16024@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 Mon, Dec 10, 2018 at 04:43:56PM -0800, speck for Linus Torvalds wrote: Ok I will inline it. FWIW the overhead is currently ~7 cycles on SKL, see [1] > 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. But the problem is how do we find all cases where someone else's data is touched? Even if I write a patch for the known to me cases I could never guarantee I found all. FWIW I suspect crypto is actually not that big an issue because most uses should be in own threads, which would be handled by the context switch flush. But at least softirqs/timers copying some user data is a real danger. > > 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. My understanding is that while this is much harder to exploit than L1TF or Meltdown, there are working exploits. -Andi [1] ffffffff818f5946 callq 0xffffffff81091960 # PRED 1 cycles [507] clear_cpu_buffers_idle: ffffffff81091960 nopl %eax, (%rax,%rax,1) ffffffff81091965 movl 0x12a3ab9(%rip), %eax ffffffff8109196b test %eax, %eax ffffffff8109196d jz 0xffffffff81091970 # PRED 1 cycles [508] 3.00 IPC ffffffff81091970 pushq %rbp ffffffff81091971 mov %rsp, %rbp ffffffff81091974 callq 0xffffffff81091940 # PRED 1 cycles [509] 2.00 IPC (it would help if we didn't disable tail calls with debug info I guess ...) clear_cpu_buffers: ffffffff81091940 nopl %eax, (%rax,%rax,1) ffffffff81091945 pushq %rbp ffffffff81091946 mov %rsp, %rbp ffffffff81091949 nopl %eax, (%rax,%rax,1) ffffffff81091951 data16 nop ffffffff81091953 popq %rbp ffffffff81091954 retq # PRED 4 cycles [513] 1.50 IPC clear_cpu_buffers_idle+25: ffffffff81091979 popq %rbp ffffffff8109197a retq # PRED 1 cycles [514] 1.00 IPC