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

[Thomas Gleixner]

Tim,

On Tue, 6 Nov 2018, Tim Chen wrote:
> >>> 2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
> >>>    in the slow work path.
> >>
> >> There can be tasks that don't do any syscalls, and it seems like we can
> >> have MSRs getting out of sync?
> > 
> > Setting the TIF flag directly in a remote task is wrong. It needs to be
> > handled when the _TIF_UPDATE_SPEC_CTRL is evaluated, i.e. the information
> > needs to be stored process wide e.g. in task->mm.
> > 
> > But yes, if the remote task runs in user space forever, it won't
> > help. Though the point is that dumpable is usually set when the process
> > starts, so it's probably mostly a theoretical issue.
> > 
> 
> I took a crack to implement what you suggested to update
> remote task's flag and remote SPEC_CTRL MSR on the syscall exit slow path.

can we please take a step back and look at the problem again?

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 ?

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?

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,

	tglx