On Tue, Jan 23, 2018 at 4:47 PM, Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> wrote: > On 01/23/2018 03:14 PM, Woodhouse, David wrote: >> On Tue, 2018-01-23 at 14:49 -0800, Andi Kleen wrote: >>>> Not sure. Maybe to start, the answer might be to allow it to be set for >>>> the ultra-paranoid, but in general don't enable it by default. Having it >>>> enabled would be an alternative to someone deciding to disable SMT, since >>>> that would have even more of a performance impact. >>> >>> I agree. A reasonable strategy would be to only enable it for >>> processes that have dumpable disabled. This should be already set for >>> high value processes like GPG, and allows others to opt-in if >>> they need to. >> >> That seems to make sense, and I think was the solution we were >> approaching for IBPB on context switch too, right? >> >> Are we generally agreed on dumpable as the criterion for both of those? >> > > 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. Also, what's the performance hit of STIBP?
