[CRIU] [PATCH 1/3] seccomp: add initial support for SECCOMP_MODE_STRICT
Pavel Emelyanov
xemul at parallels.com
Tue Jun 2 06:59:37 PDT 2015
>>>>> + int status;
>>>>> +
>>>>> + /*
>>>>> + * Since the process is going to restore seccomp state, we
>>>>> + * need to temporarily suspend seccomp before we restore this
>>>>> + * state, otherwise subsequent restore syscalls might be
>>>>> + * blocked. seccomp is resumed at the end in finalize_restore()
>>>>> + */
>>>>> + if (ptrace(PTRACE_ATTACH, ret, NULL, NULL) < 0) {
>>>>> + pr_perror("ptrace attach failed");
>>>>> + kill(ret, SIGKILL);
>>>>> + goto err_unlock;
>>>>> + }
>>>>> +
>>>>> + if (waitpid(ret, &status, 0) < 0) {
>>>>> + pr_perror("waidpid failed");
>>>>> + kill(ret, SIGKILL);
>>>>> + goto err_unlock;
>>>>> + }
>>>>> +
>>>>> + if (!WIFSTOPPED(status)) {
>>>>> + pr_err("not stopped after ptrace attach?\n");
>>>>> + kill(ret, SIGKILL);
>>>>> + goto err_unlock;
>>>>> + }
>>>>> +
>>>>> + if (ptrace(PTRACE_SUSPEND_SECCOMP, ret, NULL, 1) < 0) {
>>>>> + pr_perror("seccomp suspend failed %d", ret);
>>>>> + kill(ret, SIGKILL);
>>>>> + goto err_unlock;
>>>>> + }
>>>>> +
>>>>> + if (ptrace(PTRACE_DETACH, ret, NULL, NULL) < 0) {
>>>>> + pr_perror("ptrace detach failed");
>>>>> + kill(ret, SIGKILL);
>>>>> + goto err_unlock;
>>>>> + }
>>
>> Oh, btw, once you implement suspend-off on ptrace detach this place will
>> stop working.
>
> Urgh, yeah. I think to avoid having the task ptraced the whole time,
> we need to add another stage to the end of the restorer blob which
> tells the task it is ok to restore seccomp because it is ptraced and
> disabled, so this code goes away entirely.
CRIU already ptraces the restored tasks at the very end -- the attach_to_tasks()
plus funalize_restore() do it to help properly remove the whole restorer blob.
Can you try to put the seccomp un-suspend into this ptrace-ing?
-- Pavel
More information about the CRIU
mailing list