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 ; 23 Jan 2019 16:02:17 -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 1gmKyl-000633-VH for speck@linutronix.de; Wed, 23 Jan 2019 17:02:16 +0100 Date: Wed, 23 Jan 2019 08:02:06 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v5 14/27] MDSv5 3 Message-ID: <20190123160206.GZ6118@tassilo.jf.intel.com> References: <8b89fce6dd87638a00078082141d3ce5fe13d0ea.1547858934.git.ak@linux.intel.com> <20190123013525.GX6118@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, Jan 23, 2019 at 10:27:36AM +0100, speck for Thomas Gleixner wrote: > On Tue, 22 Jan 2019, speck for Andi Kleen wrote: > > > The only thing which is not covered are functions in syscall context which > > > touch sensitive data which does not belong to the process. > > > > It's also cryptographic keys. > > > > > Do they actually exist? If so, then and only then you need the full > > > > There is plenty crypto code in process context at least. > > Sure, but the question is whether these keys belong to the process or > not. If they do, then what's the leak? They often do not. A standard case is file system (network or disk) keys. If you leaked your file system keys to every application which can access something then all file system permissions can be violated. > > You really want to provide a proper analysis of what can be leaked in which > context?. ?!? I provided a full document with my security model as part of the patchkit. If you think something is missing in my model please comment on it directly instead of just giving vague statements. If the consensus is that partial mitigation is sufficient I can look into it, but I would like stronger statements on this from more reviewers (including distribution vendors) For example on Spectre we had the problem that some distributions didn't trust the upstream solutions enough and ended up developing their stronger mitigation. I would like to avoid this problem here, and have a consensus default solution that works for everyone. Based on the performance data I've seen I don't see any reason to do anything less secure than my current patch kit. > you just sprinkle random mitigation calls around. > > The point is that paranoid mitigation is simply 'always invoke VERW'. The > conditional modes and that's what we have done for the other > vulnerabilities as well are handling the most obvious issues and leave some > documented holes. Trying to catch everything in cond mode is just adding a > lot of pointless crap all over the code base and will still fail to plug > all holes unless you do a full audit of all kernel code. > > It would be interesting to see the following test results: You mean performance test results? That's in 0/0 The worse case slow down we've seen with the lazy flushing is ~2% (on a benchmark that pushes data over loopback in a tight loop). Most workloads see no change because the existing lazy scheme works fairly well. With full flushing the worst case seen is 8%, but again that was a workload that does syscalls in a tight loop, so more an outlier. -Andi