linux-kernel - Re: [RFC PATCH] proc, pidns: Add highpid

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: <547C6022.1030904@parallels.com>
Date:	Mon, 1 Dec 2014 15:33:38 +0300
From:	Pavel Emelyanov <xemul@...allels.com>
To:	Florian Weimer <fw@...eb.enyo.de>,
	Andy Lutomirski <luto@...capital.net>
CC:	<criu@...nvz.org>, Cyrill Gorcunov <gorcunov@...nvz.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	David Herrmann <dh.herrmann@...il.com>,
	systemd Mailing List <systemd-devel@...ts.freedesktop.org>,
	Linux API <linux-api@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] proc, pidns: Add highpid

On 12/01/2014 09:47 AM, Florian Weimer wrote:
> * Andy Lutomirski:
> 
>> On Nov 30, 2014 1:47 AM, "Florian Weimer" <fw@...eb.enyo.de> wrote:
>>>
>>> * Andy Lutomirski:
>>>
>>>> The initial implementation is straightforward: highpid is simply a
>>>> 64-bit counter. If a high-end system can fork every 3 ns (which
>>>> would be amazing, given that just allocating a pid requires at
>>>> atomic operation), it would take well over 1000 years for highpid to
>>>> wrap.
>>>
>>> I'm not sure if I'm reading the patch correctly, but is the counter
>>> namespaced?  If yes, why?
>>
>> It's namespaced so that CRIU can migrate/restore a whole pid namespace.
> 
> Oh well, this requirement is at odds with system-wide uniqueness.  Is
> CRIU really that important? :-)

Well, in this context it is. Since the main (if not the only) use-case for
highpid is to read one, remember, then compare to new value, restoring it
to wrong/arbitrary value will break the using applications in 100% cases.

Thus we really need the ability to restore this value.

Thanks,
Pavel

--
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/