linux-kernel - Re: [External] Re: [PATCH] pid_ns: support pidns switching between sibling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEEQ3wk-faMz3pRtc-n_zSTo3B=GjHeDH4PMN0EJT6=HPVGZ=A@mail.gmail.com>
Date:   Fri, 13 Oct 2023 16:55:58 +0800
From:   yunhui cui <cuiyunhui@...edance.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     akpm@...ux-foundation.org, keescook@...omium.org,
        brauner@...nel.org, jeffxu@...gle.com, frederic@...nel.org,
        mcgrof@...nel.org, cyphar@...har.com, rongtao@...tc.cn,
        linux-kernel@...r.kernel.org,
        Linux Containers <containers@...ts.linux.dev>
Subject: Re: [External] Re: [PATCH] pid_ns: support pidns switching between sibling

Hi Eric,

On Fri, Oct 13, 2023 at 10:44 AM yunhui cui <cuiyunhui@...edance.com> wrote:
>
> Hi Eric,
>
> On Thu, Oct 12, 2023 at 11:31 AM Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
> >
> > Yunhui Cui <cuiyunhui@...edance.com> writes:
> >
> > > In the scenario of container acceleration,
> >
> > What is container acceleration?
> >
> > Are you perhaps performing what is essentially checkpoint/restart
> > from one set of processes to a new set of processes so you can
> > get a container starting faster?
> Yeah, you are right .
>
> >
> > > when a target pstree is cloned from a temp pstree, we hope that the
> > > cloned process is inherently in the target's pid namespace.
> >
> > I am having a hard time figuring out what you are saying here.
>
> I think I need to describe in detail our needs and problems we face.
> What we need to do is fork a container into a new container, which
> means that all
> processes of the original container need to be forked out and added to
> the new container.
> Then the forked process needs to be added to the namespace and cgroup
> of the new container.
>
> What we are talking about here is the pid namespace.
>
> for example:
> Assume that there are three processes A, B, and C in the original container.
> What we need to do is A fork A_new, B fork B_new, C fork C_new.
>
> However, in the existing pidns implementation, the parent process
> first joins pidns, and then
> the forked child process will get the new pidns (the pid of the child
> process is what we expected),
> and the parent process's own pidns has not actually changed (at least
> pid is still existing).
>
> To make A_new, B_new, and C_new inherently in the pidns of the new container,
> A, B, and C must first switch to the pidns of the new container, right?
> From my understanding there is no better way to implement it.
>
> But the existing implementation (the part to be changed in this patch)
> is blocking our progress.
>
> >
> > > Examples of what we expected:
> > >
> > > /* switch to target ns first. */
> > > setns(target_ns, CLONE_NEWPID);
> >   ^-------- Is this the line that fails for you?

Yes, it failed here.

Thanks,
Yunhui