[CRIU] [PATCH v2 1/3] seccomp: add initial support for SECCOMP_MODE_STRICT

[Tycho Andersen]

On Thu, Jun 04, 2015 at 03:34:07PM +0300, Pavel Emelyanov wrote:
> 
> >>>  	}
> >>>  
> >>> @@ -1632,6 +1634,9 @@ static int attach_to_tasks(bool root_seized, enum trace_flags *flag)
> >>>  				return -1;
> >>>  			}
> >>>  
> >>> +			if (suspend_seccomp(pid) < 0)
> >>> +				return -1;
> >>
> >> BTW, why do we need to suspend seccomp on restore? The sigreturn is allowed in strict
> >> mode so if we just turn one ON before it nothing bad will (should) happen.
> > 
> > Because the unmap of the parasite blob happens after this (in
> > finalize_restore() via ptrace), and if that isn't allowed the task is
> > killed.
> 
> Ah, indeed :( But then things look even simpler and we don't need separate stage :)
> 
> Look, the pie/restorer.c just turns seccomp on one line before calling sigreturn
> and does so. While doing this call it will be stopped up by criu with ptrace. And,
> once criu did this, it should check whether seccomp is ON, suspend it if required
> and continue task's execution.
> 
> Does it make sense?

...and while fixing this, I realized that my poor understanding of
kernel threads meant that I'm only c/r-ing the seccomp state from the
first thread in the threadgroup, when in fact we should do it for all
of them (I'm looking in /proc/pid/status instead of
/proc/pid/task/tid/status, and only doing the restore once per pid
instead of per thread).

This probably means that the lsm stuff is wrong too, since it seems
that can happen per thread as well, IIUC.

Tycho