Messages in this thread | | | From | Tim Chen <> | Subject | Re: [Patch v4 17/18] x86/speculation: Update SPEC_CTRL MSRs of remote CPUs | Date | Wed, 7 Nov 2018 16:22:47 -0800 |
| |
Thomas,
> > The goal is to glue the mitigation decision on dumpable. That's debatable, > but understandable, so let's not go into that discussion. > > There are two ways to modify dumpable: > > 1) prctl(PR_SET_DUMPABLE) > > 2) operations which change UID/GID and end up in commit_creds() > > Now the really interesting question is _when_ is any of the above invoked: > > 1) When the process is still single threaded ? > > 2) When the process has already spawned threads ? >
The UID/GID changes in setuid and setgid syscalls are applied to the thread only. There's no propagation of the cred change to other related threads. So if the user process expect the change to propagate to other related threads, they should do setuid/setgid before they spawn other threads.
I think similar logic should apply for prctl(PR_SET_DUMPABLE) that the user expects the change to be for the current task and the propagation of this change to other threads is a side effect.
Will anyone mind if we put in restriction that prctl(PR_SET_DUMPABLE) should only be done when a task is single threaded?
Otherwise the user process should only expect the current thread to get the benefit of STIBP protection when setting it to non-dumpable. I can add comments in the code to explain this.
> If #2 is just the oddball exception, then why on earth should we go through > loops and hoops to make it work and add overhead in hot paths for no real > value? >
I tend to agree with you on this.
> So what we really want before discussing any potential solutions and their > pro and cons is an answer to that. > > If we don't have that answer, then we might just create a purely academic > solution which creates more problems than it solves. >
Thanks.
Tim
| |