> > 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), 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)
