Re: [Patch v4 17/18] x86/speculation: Update SPEC_CTRL MSRs of remote CPUs

[Tim Chen <tim.c.chen@linux.intel.com>]

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