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
| ||
|
Date: Sat, 29 Nov 2014 19:06:59 +0300 From: Cyrill Gorcunov <gorcunov@...il.com> To: Andy Lutomirski <luto@...capital.net> Cc: David Herrmann <dh.herrmann@...il.com>, linux-api@...r.kernel.org, linux-kernel@...r.kernel.org, "Eric W. Biederman" <ebiederm@...ssion.com>, Andrew Morton <akpm@...ux-foundation.org>, systemd Mailing List <systemd-devel@...ts.freedesktop.org> Subject: Re: [RFC PATCH] proc, pidns: Add highpid On Fri, Nov 28, 2014 at 03:05:01PM -0800, Andy Lutomirski wrote: > Pid reuse is common, which means that it's difficult or impossible > to read information about a pid from /proc without races. > > This introduces a second number associated with each (task, pidns) > pair called highpid. Highpid is a 64-bit number, and, barring > extremely unlikely circumstances or outright error, a (highpid, pid) > will never be reused. > > With just this change, a program can open /proc/PID/status, read the > "Highpid" field, and confirm that it has the expected value. If the > pid has been reused, then highpid will be different. > > 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. > > For CRIU's benefit, the next highpid can be set by a privileged > user. > > NB: The sysctl stuff only works on 64-bit systems. If the approach > looks good, I'll fix that somehow. > > Signed-off-by: Andy Lutomirski <luto@...capital.net> > --- > > If this goes in, there's plenty of room to add new interfaces to > make this more useful. For example, we could add a fancier tgkill > that adds and validates hightgid and highpid, and we might want to > add a syscall to read one's own hightgid and highpid. These would > be quite useful for pidfiles. > > David, would this be useful for kdbus? > > CRIU people: will this be unduly difficult to support in CRIU? Hi Andy. I think it won't be hard to support. -- 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/
Powered by blists - more mailing lists