> On Jan 23, 2018, at 5:59 PM, Van De Ven, Arjan <[email protected]> > wrote: > > >>> It is a reasonable approach. Let a process who needs max security >>> opt in with disabled dumpable. It can have a flush with IBPB clear before >>> starting to run, and have STIBP set while running. >>> >> >> Do we maybe want a separate opt in? I can easily imagine things like >> web browsers that *don't* want to be non-dumpable but do want this >> opt-in. > > eventually we need something better. Probably in addition. > dumpable is used today for things that want this. > >> >> Also, what's the performance hit of STIBP? > > pretty steep, but it depends on the CPU generation, for some it's cheaper > than others. (yes I realize this is a vague answer, but the range is really > from just about zero to oh my god) > > I'm not a fan of doing this right now to be honest. We really need to not > piece meal some of this, and come up with a better concept of protection on a > higher level. > For example, you mention web browsers, but the threat model for browsers is > generally internet content. For V2 to work you need to get some "evil > pointer" into the app from the observer and browsers usually aren't doing > that. > The most likely user would be some software-TPM-like service that has magic > keys. > > And for keys we want something else... we want an madvice() sort of thing > that does a few things, like equivalent of mlock (so the key does not end up > in swap),
I'd love to see a slight variant: encrypt that page against some ephemeral key if it gets swapped. > not having the page (but potentially the rest) end up in core dumps, and the > kernel making sure that if the program exits (say for segv) that the key page > gets zeroed before going into the free pool. Once you do that as feature, > making the key speculation safe is not too hard (intel and arm have cpu > options to mark pages for that) > > How do we do that on Intel? Make it UC?
