[CRIU] is CR_STATE_RESTORE_CREDS necessary?

[Andrey Wagin]

2015-12-09 20:05 GMT+03:00 Tycho Andersen <tycho.andersen at canonical.com>:
> Hi all,
>
> I'm trying to figure out a way to get rid of this FIXME:
> https://github.com/xemul/criu/blob/master/test/zdtm/live/static/seccomp_filter.c#L103
>
> to do this, we need to call restore_seccomp() before restore_creds(),
> but if we're doing that, we need to suspend seccomp so that it doesn't
> kill the task if the policy has blocked some syscall that
> restore_creds does.
>
> Right now, seccomp is suspended in attach_to_tasks(), because that's
> the last ptrace attach that criu does to the tasks. However, that
> happens after CR_STATE_RESTORE_CREDS, i.e. after the creds are
> restored.

CR_STATE_RESTORE_CREDS is the last synchronization point. We stop on
__NR_sigreturn with help of ptrace, but it doesn't work if we trace
"criu restore". I use strace to investigate bugs very often.

strace -fo strace.log -s 256 ./criu restore ...

I would like to save this ability if it's possible.

>
> I could just move the attach_to_tasks call above
> CR_STATE_RESTORE_CREDS, but I think that would deadlock since the main criu
> tasks waits for the tasks to be complete, but they're all in the
> stopped state (because we'd have ptraced them), and the loop that lets
> them run is in parasite_stop_on_syscall much further below.

We use breakpoints for x86_64. Maybe we can use them for other arch-s.
Or we can attach tasks, suspend seccomp for them and resume them back
and then interrupt them again after CR_STATE_RESTORE_CREDS.

And there is another reason to have CR_STATE_RESTORE_CREDS. It allows
us to reduce the number of syscalls which we need to trace with
PTRACE_SYSCALL, because it works slow.


Thanks,
Andrew

>
> My idea here is to get rid of this CR_STATE_RESTORE_CREDS and just
> ptrace attach after CR_STATE_RESTORE_SIGCHLD and run the loop there.
> But, I'm not sure if CR_STATE_RESTORE_CREDS is used for anything. It
> doesn't seem necessary, but probably I'm missing something :)
>
> Tycho
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu