linux-kernel - Re: [PATCH] Add /proc/pid

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: <20181122111930.GA7164@ip-172-31-15-78>
Date:   Thu, 22 Nov 2018 11:19:30 +0000
From:   Kevin Easton <kevin@...rana.org>
To:     Daniel Colascione <dancol@...gle.com>
Cc:     linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        timmurray@...gle.com, primiano@...gle.com, joelaf@...gle.com,
        Jonathan Corbet <corbet@....net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Roman Gushchin <guro@...com>, Vlastimil Babka <vbabka@...e.cz>,
        "Dennis Zhou (Facebook)" <dennisszhou@...il.com>,
        Prashant Dhamdhere <pdhamdhe@...hat.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Pavel Tatashin <pasha.tatashin@...cle.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Michal Hocko <mhocko@...e.com>, MatthewWilcox@...172-31-15-78
Subject: Re: [PATCH] Add /proc/pid_generation

On Wed, Nov 21, 2018 at 12:14:44PM -0800, Daniel Colascione wrote:
> This change adds a per-pid-namespace 64-bit generation number,
> incremented on PID rollover, and exposes it via a new proc file
> /proc/pid_generation. By examining this file before and after /proc
> enumeration, user code can detect the potential reuse of a PID and
> restart the task enumeration process, repeating until it gets a
> coherent snapshot.

I see downthread this patch has been withdrawn, but nonetheless I'm
still curious - does this actually solve the problem?

It seems to me that a PID could be reused within a scan even if the
generation number remains the same at the beginning and end of a scan:

Say you have a very long-lived task with PID 500 allocated in generation
0.  The PID creation has since wrapped and we are now allocating from the
start of the range again, with generation 1.  We begin a scan of /proc, 
read the generation (1) and at this point, our task dies and PID 500 is
then reallocated to a new task.  We finish our scan, generation is still
1 but PID 500 is now ambiguous.

Am I wrong?

    - Kevin