[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