On Wed, Nov 21, 2018 at 12:07 PM Dave Hansen dave.hansen@intel.com wrote:
Repurposing dumpable is really screwy and surely imprecise, but it really is the closest thing that we have without the new ABI.
But we *have* a new ABI.
So that's not a valid argument.
It's more like "this other thing that some other users use for something *entirely* different has in _one_ case the semantics you'd want, but in most cases not at all".
Because gpg really is the odd man out.
And it's not at all obvious that you can attack gpg using the hole that STIBP opens, when there are other timing attacks that are likely as good or better, and when we know that people who really care about the issue are already just disabling SMT entirely.
That's really the basic issue here: STIBP has horrible overhead, _and_ it's not even targeting the people who really want it, so we'd better be very targeted in how it's used.
Because we already know how badly things messed up when the use of STIBP wasn't targeted.
The _only_ very real and direct advantage "dumpable" has is that it hides the problem from benchmarks. Because benchmarks don't test non-dumpable processes.
But honestly, that sounds like a disadvantage to me. It smells like "let's hide the overhead dishonestly".
Linus