[CRIU] [PATCH 1/2] don't assume the kernel has CONFIG_SECCOMP

[Tycho Andersen]

On Thu, Jun 25, 2015 at 06:25:38PM +0300, Pavel Emelyanov wrote:
> On 06/25/2015 06:18 PM, Tycho Andersen wrote:
> > On Thu, Jun 25, 2015 at 06:15:43PM +0300, Pavel Emelyanov wrote:
> >>
> >>>> Why is this required? If criu finds seccomp mark in /proc, then shouldn't
> >>>> it properly parse one?
> >>>
> >>> The problem is when it doesn't have Seccomp:. We won't get to 9 things
> >>> parsed, even though we check for 9 things. I suppose it's not strictly
> >>> necessary in the while() loop, but the check for success below
> >>> requires it.
> >>
> >> Ah, but then this check is not about CONFIG_HAS_SECCOMP (user space library) but
> >> purely about kernel. Either we meet one there or not, but we should not depend on 
> >> the userspace library presence.
> > 
> > We're not depending on the library presence, are we? 
> 
> Well, this hunk
> 
> @@ -780,7 +785,13 @@ int parse_pid_status(pid_t pid, struct proc_status_creds *cr)
>  	if (bfdopenr(&f))
>  		return -1;
>  
> -	while (done < 9) {
> +#ifdef CONFIG_HAS_SECCOMP
> +#define THINGS_TO_PARSE 9
> +#else
> +#define THINGS_TO_PARSE 8
> +#endif
> +
> +	while (done < THINGS_TO_PARSE) {
>  		str = breadline(&f);
>  		if (str == NULL)
>  			break;
> 
> from patch #1 brings one :) If there's no seccomp.h header on the system the proc
> parsing code starts ignoring the Seccomp: field. While the field presence doesn't
> depend on it.

The header is linux/seccomp.h though, which is a kernel header (vs.
just seccomp.h, which is libseccomp).

> > The problem is
> > that a /proc/pid/status entry will simply not have a line containing
> > "Seccomp:" if it is kernel 3.11, but if we expect it to be there (by
> > requiring 9 successful things to parse), we will always fail on a 3.11
> > kernel.
> 
> Yes, but on the other hand, if we don't have seccomp.h while process is seccomp-ed
> we will ignore this fact.

I guess there is a problem of what if you build an old criu and
upgrade your kernel to a new one that supports seccomp, so we probably
do need something a little better here.

Tycho