<div dir="ltr">The earliest I can work on cr_check() patch would be Tuesday next week which is unfortunately after the freeze date of February 22nd. Do you still want me to do so?<div><br></div><div>--Saied</div><div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 2:49 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@virtuozzo.com" target="_blank">xemul@virtuozzo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/17/2016 09:15 PM, Saied Kazemi wrote:<br>
<span class="">> On Wed, Feb 17, 2016 at 9:36 AM, Pavel Emelyanov <<a href="mailto:xemul@virtuozzo.com">xemul@virtuozzo.com</a> <mailto:<a href="mailto:xemul@virtuozzo.com">xemul@virtuozzo.com</a>>> wrote:<br>
><br>
> On 02/17/2016 08:27 PM, Saied Kazemi wrote:<br>
> > I am running the containers with --security-opt seccomp:unconfined option,<br>
> > so there should be no security risks.<br>
><br>
> Ouch. Why does criu then sees some seccomp configured on it?<br>
><br>
><br>
> I think I know what happened. I had a script that would build and install CRIU and then test Docker<br>
> checkpoint and restore. The script was failing because criu check was failing but somehow I assumed<br>
> that it was criu dump that was failing although --security-opt seccomp:unconfined option was used.<br>
> Sorry for the confusion :(<br>
<br>
</span>Ah, I see. I will then roll-back Tycho's patch not to burden the API with the<br>
stuff we don't really need. OK?<br>
<span class=""><br>
> > Now what can we do to make criu check pass when running on kernels that<br>
> > don't have seccomp? The section "Checking That It Works" in<br>
> > <a href="http://criu.org/Installation" rel="noreferrer" target="_blank">http://criu.org/Installation</a> says that the users should see "Looks OK".<br>
> > But currently we can't get a "Looks OK" message even with --no-seccomp.<br>
> > Pavel had a suggestion on how to redo criu check.<br>
><br>
> Yup. We should distinguish tree types of features -- those, that are strictly<br>
> required to make things work (/proc/pid/map_files, ptrace PEEKSIGINFO ,etc),<br>
> those that are required, but only for "specific cases" (aio remap, tun, etc)<br>
> and those that are experimental (e.g. task-diag from Andrey).<br>
><br>
><br>
> The 3-mode scheme sounds reasonable but which modes are absolutely necessary for<br>
> CRIU to dump and restore successfully.<br>
<br>
</span>Looking at cr_check() I think that we 100% need everything till check_ptrace_peeksiginfo,<br>
as pretty much every task uses what we check with it.<br>
<br>
All the other stuff is optional and criu can succeed w/o them.<br>
<br>
And, by now, we have no experimental features in criu that require non-upstream kernel.<br>
<span class=""><br>
> We maintained in the past that if users don't get "Looks OK" from criu check they won't<br>
> be able to dump/restore. But that's not the case anymore as criu check fails with<br>
> seccomp errors but it successfully dumps and restores.<br>
<br>
</span>Yes, I agree. Would you be able to prepare the patch to fix the cr-check untill<br>
criu-2.0 release?<br>
<span class=""><br>
> But as far as seccomp is concerned, I'm now in doubt -- if there's no seccomp<br>
> configured on a task, criu should just dump it even if there's no support<br>
> from kernel to dump seccomp. But this seems not to be the case for Saied.<br>
><br>
><br>
> Per my explanation above, sorry for the false alarm!<br>
<br>
</span>That's OK :) Given enough eyeballs, all bugs are shallow.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Pavel<br>
<br>
</font></span></blockquote></div><br></div>