linux-kernel - Re: [PATCH v3 1/5] pidfd: check pid has attached task in fdinfo

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] [day] [month] [year] [list]

Message-ID: <20191018150526.mgmucts33p7gspqo@wittgenstein>
Date:   Fri, 18 Oct 2019 17:05:27 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     oleg@...hat.com, linux-kernel@...r.kernel.org
Cc:     aarcange@...hat.com, akpm@...ux-foundation.org,
        christian@...lner.me, cyphar@...har.com, elena.reshetova@...el.com,
        guro@...com, jannh@...gle.com, ldv@...linux.org,
        linux-api@...r.kernel.org, linux-kselftest@...r.kernel.org,
        mhocko@...e.com, mingo@...nel.org, peterz@...radead.org,
        shuah@...nel.org, tglx@...utronix.de, viro@...iv.linux.org.uk
Subject: Re: [PATCH v3 1/5] pidfd: check pid has attached task in fdinfo

On Thu, Oct 17, 2019 at 12:18:28PM +0200, Christian Brauner wrote:
> Currently, when a task is dead we still print the pid it used to use in
> the fdinfo files of its pidfds. This doesn't make much sense since the
> pid may have already been reused. So verify that the task is still alive
> by introducing the pid_has_task() helper which will be used by other
> callers in follow-up patches.
> If the task is not alive anymore, we will print -1. This allows us to
> differentiate between a task not being present in a given pid namespace
> - in which case we already print 0 - and a task having been reaped.
> 
> Note that this uses PIDTYPE_PID for the check. Technically, we could've
> checked PIDTYPE_TGID since pidfds currently only refer to thread-group
> leaders but if they won't anymore in the future then this check becomes
> problematic without it being immediately obvious to non-experts imho. If
> a thread is created via clone(CLONE_THREAD) than struct pid has a single
> non-empty list pid->tasks[PIDTYPE_PID] and this pid can't be used as a
> PIDTYPE_TGID meaning pid->tasks[PIDTYPE_TGID] will return NULL even
> though the thread-group leader might still be very much alive. So
> checking PIDTYPE_PID is fine and is easier to maintain should we ever
> allow pidfds to refer to threads.
> 
> Cc: Jann Horn <jannh@...gle.com>
> Cc: Christian Kellner <christian@...lner.me>
> Cc: linux-api@...r.kernel.org
> Signed-off-by: Christian Brauner <christian.brauner@...ntu.com>
> Reviewed-by: Oleg Nesterov <oleg@...hat.com>

Applied this series to:
https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=pidfd

Thanks!
Christian