[MODERATED] Re: [PATCH SSBv11 3/3] seccomp 0

[Kees Cook <kees@outflux.net>]

On Thu, May 03, 2018 at 11:21:36AM +0200, speck for Thomas Gleixner wrote:
> On Thu, 3 May 2018, speck for Peter Zijlstra wrote:
> > On Tue, May 01, 2018 at 03:07:31PM -0700, speck for Kees Cook wrote:
> > > @@ -239,6 +254,9 @@ static inline void seccomp_assign_mode(struct task_struct *task,
> > >  	 */
> > >  	smp_mb__before_atomic();
> > >  	set_tsk_thread_flag(task, TIF_SECCOMP);
> > > +
> > > +	/* Assume seccomp processes want speculation flaw mitigation. */
> > > +	spec_mitigate(task, PR_SPEC_STORE_BYPASS);
> > >  }
> > 
> > What about the ordering there? That function appears to explicitly set
> > TIF_SECCOMP last, such that when that is observed, the complete
> > environment is observed.
> > 
> > But now you add something after it. Does this not mean that if you set
> > this on a remote task, this task can execute TIF_SECCOMP thing before it
> > disables SSB.
> > 
> > Is that OK?
> 
> It probably should be the other way round.

I can swap it around. For the seccomp case, it's a thread in the current
thread group, so it's not TOTALLY remote. :) In the case of thread-sync for
seccomp, it is expected to be "correct at next scheduling".

-Kees

-- 
Kees Cook                                            @outflux.net