[MODERATED] Re: [patch V2 09/10] MDS basics+ 9

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