linux-kernel - Re: [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids

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]

Date:	Mon, 28 Nov 2011 08:25:38 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Pavel Emelyanov <xemul@...allels.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Pedro Alves <pedro@...esourcery.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	James Bottomley <jbottomley@...allels.com>
Subject: Re: [RFC][PATCH 0/3] fork: Add the ability to create tasks with
 given pids

Hello, Pavel.

On Mon, Nov 28, 2011 at 02:38:46PM +0400, Pavel Emelyanov wrote:
> > Hmmm... Any attempt to reserve PIDs without full control over the
> > namespace is futile.  It can never be complete / reliable. 
> 
> Why? What's the _real_ problem with the 
> 
> pid = prctl(PR_RESERVE_PID, 0); /* let the kernel _generate_ a pid for us */
> while (1) {
> 	real_pid = fork();
> 	BUG_ON(pid != real_pid);
> 	if (real_pid == 0)
> 		return do_child();
> 
> 	wait();
> }
> 
> model? Let's temporarily forget about the single reserved pid implementation
> limitation and concentrate on the approach itself.

PID is ns-shared resource.  If you don't have full control over it and
there are other tasks allocating from it, there is no way to reserve
specific pid reliably no matter what you do.  The only things you can
do are - either reserve the pids you want before anyone else takes it
or somehow revoke pids held by other tasks.

Full ns control + set_last_pid essentially gives the ns owner full
reservation + a way to control allocation.

I suppose you're suggesting that with reserve approach, we can also
support recycling pids of existing tasks which is suggested to be
useful for systemd and gdb.

Using this kind of black magic for general system management seems
like a really bad idea to me.  It is extremely obscure and unexpected
and we actually should be looking to dissuade such usage even if the
natural implementation of the mechanism allows for it.

For gdb, it *might* be useful but the usage isn't out there yet and
the suggested mechanism isn't enough to support the suggested usage
(ie. multithread).  We have neither concrete problem or solution.

So, let's do the simple 30 line non-invasive thing now and worry about
the complex problem when it's actually necessary.  It's not like the
ability to set last_pid is gonna interfere with future changes or
anything.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/