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 ; 21 Feb 2019 18:00:39 -0000 Received: from mta.outflux.net ([2001:19d0:2:6:c0de:0:736d:7471] helo=smtp.outflux.net) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gwseC-0005zN-MO for speck@linutronix.de; Thu, 21 Feb 2019 19:00:38 +0100 Received: from www.outflux.net (serenity.outflux.net [10.2.0.2]) by vinyl.outflux.net (8.15.2/8.15.2/Debian-10) with ESMTP id x1LI0TsG020817 for ; Thu, 21 Feb 2019 10:00:29 -0800 Date: Thu, 21 Feb 2019 10:00:29 -0800 From: Kees Cook Subject: [MODERATED] Re: [patch V2 09/10] MDS basics+ 9 Message-ID: <20190221180029.GT6084@outflux.net> References: <20190220150753.665964899@linutronix.de> <20190220151400.787843957@linutronix.de> MIME-Version: 1.0 In-Reply-To: <20190220151400.787843957@linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Feb 20, 2019 at 04:08:02PM +0100, speck for Thomas Gleixner wrote: > - A helper function to set the flush request. Is in processor.h for now to > avoid include hell, but might move to a separate header. So, this looks like a blacklisting approach? i.e. things that feel they are sensitive must call this to make sure they don't leak. I think we'd have safer coverage if we did this in reverse: we're likely better able to reason about places where we know there's nothing interesting happening and we don't need to flush. (i.e. whitelist and flush by default) Now, all that said, I think we need to always flush, but I'm paranoid and I look at exploits too much. For example, even stack addresses themselves should be considered secret, since they may be used by attackers to align cross-stack attacks, etc. Take a look at the hoops that are needed to pull this attack off: https://www.slideshare.net/scovetta/stackjacking I don't think we should make this easier by default. The same applies to all heap addresses, and basically everything. Just blacklisting externally-defined "secrets" isn't going to protect much, IMO. Discoverability of kernel memory layout (and I'm not talking text ASLR here: I mean stack, heap, page table location, etc) is basically the second step of modern attacks. (The first step is usually turning off SMAP.) So, for the paranoid: we need a flush-always. For people who think attackers aren't going to use 0-day bugs and all the leaky info to perform a "regular" memory corruption attack to gain access to "secrets", and want to just stop direct leaks, I think whitelisting is the better option. How can we know what someone thinks is a secret? -- Kees Cook @outflux.net