From: Kees Cook <kees@outflux.net>
To: speck@linutronix.de
Subject: [MODERATED] Re: [patch V2 09/10] MDS basics+ 9
Date: Thu, 21 Feb 2019 10:00:29 -0800 [thread overview]
Message-ID: <20190221180029.GT6084@outflux.net> (raw)
In-Reply-To: <20190220151400.787843957@linutronix.de>
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
next prev parent reply other threads:[~2019-02-21 18:00 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-20 15:07 [patch V2 00/10] MDS basics+ 0 Thomas Gleixner
2019-02-20 15:07 ` [patch V2 01/10] MDS basics+ 1 Thomas Gleixner
2019-02-20 16:27 ` [MODERATED] " Borislav Petkov
2019-02-20 16:46 ` Greg KH
2019-02-20 15:07 ` [patch V2 02/10] MDS basics+ 2 Thomas Gleixner
2019-02-20 16:47 ` [MODERATED] " Borislav Petkov
2019-02-20 16:48 ` Greg KH
2019-02-20 15:07 ` [patch V2 03/10] MDS basics+ 3 Thomas Gleixner
2019-02-20 16:54 ` [MODERATED] " mark gross
2019-02-20 16:57 ` Thomas Gleixner
2019-02-20 18:08 ` [MODERATED] " mark gross
2019-02-20 21:40 ` Thomas Gleixner
2019-02-20 17:14 ` [MODERATED] " Borislav Petkov
2019-02-20 21:31 ` Thomas Gleixner
2019-02-21 2:12 ` [MODERATED] " Andrew Cooper
2019-02-21 9:27 ` Peter Zijlstra
2019-02-21 9:33 ` [MODERATED] " Borislav Petkov
2019-02-21 10:04 ` Thomas Gleixner
2019-02-21 10:18 ` [MODERATED] Re: " Borislav Petkov
2019-02-20 15:07 ` [patch V2 04/10] MDS basics+ 4 Thomas Gleixner
2019-02-20 16:52 ` [MODERATED] " Greg KH
2019-02-20 17:10 ` mark gross
2019-02-21 19:26 ` [MODERATED] Encrypted Message Tim Chen
2019-02-21 20:32 ` Thomas Gleixner
2019-02-21 21:07 ` [MODERATED] " Jiri Kosina
2019-02-20 18:43 ` [MODERATED] Re: [patch V2 04/10] MDS basics+ 4 Borislav Petkov
2019-02-20 19:26 ` Jiri Kosina
2019-02-20 21:42 ` Thomas Gleixner
2019-02-20 15:07 ` [patch V2 05/10] MDS basics+ 5 Thomas Gleixner
2019-02-20 20:05 ` [MODERATED] " Borislav Petkov
2019-02-21 2:24 ` Andrew Cooper
2019-02-21 10:36 ` Thomas Gleixner
2019-02-21 11:22 ` Thomas Gleixner
2019-02-21 11:51 ` [MODERATED] Attack Surface [Was [patch V2 05/10] MDS basics+ 5] Andrew Cooper
2019-02-21 18:41 ` Thomas Gleixner
2019-02-20 15:07 ` [patch V2 06/10] MDS basics+ 6 Thomas Gleixner
2019-02-21 10:18 ` [MODERATED] " Borislav Petkov
2019-02-20 15:08 ` [patch V2 07/10] MDS basics+ 7 Thomas Gleixner
2019-02-21 12:47 ` [MODERATED] " Borislav Petkov
2019-02-21 13:48 ` Thomas Gleixner
2019-02-20 15:08 ` [patch V2 08/10] MDS basics+ 8 Thomas Gleixner
2019-02-21 14:04 ` [MODERATED] " Borislav Petkov
2019-02-21 14:11 ` Thomas Gleixner
2019-02-20 15:08 ` [patch V2 09/10] MDS basics+ 9 Thomas Gleixner
2019-02-20 16:21 ` [MODERATED] " Peter Zijlstra
2019-02-20 22:32 ` Thomas Gleixner
2019-02-20 22:50 ` [MODERATED] " Jiri Kosina
2019-02-20 23:22 ` Thomas Gleixner
2019-02-21 11:04 ` [MODERATED] " Peter Zijlstra
2019-02-21 11:50 ` Peter Zijlstra
2019-02-21 14:18 ` Borislav Petkov
2019-02-21 18:00 ` Kees Cook [this message]
2019-02-21 19:46 ` Thomas Gleixner
2019-02-21 20:56 ` Thomas Gleixner
2019-02-20 15:08 ` [patch V2 10/10] MDS basics+ 10 Thomas Gleixner
2019-02-22 16:05 ` [MODERATED] Re: [patch V2 00/10] MDS basics+ 0 mark gross
2019-02-22 17:12 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190221180029.GT6084@outflux.net \
--to=kees@outflux.net \
--cc=speck@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.