linux-kernel - Re: [PATCH v5] pidfd: add ioctl to retrieve pid info

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: <CAMw=ZnQUfCy2RBHdkBJ9r-tK5OBidQd=zCKHeJGcfprj4+ELJg@mail.gmail.com>
Date: Sun, 6 Oct 2024 22:33:08 +0100
From: Luca Boccassi <luca.boccassi@...il.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: linux-kernel@...r.kernel.org, christian@...uner.io
Subject: Re: [PATCH v5] pidfd: add ioctl to retrieve pid info

On Sun, 6 Oct 2024 at 19:56, Oleg Nesterov <oleg@...hat.com> wrote:
>
> On 10/06, Luca Boccassi wrote:
> >
> > I see, so what should I do here then? Check both? Or none?
>
> I don't know, because I don't know how are you going to use this API.
>
> > The caller
> > needs to verify that the data is still valid at the point they use it
> > anyway,
>
> So "none" should work fine? Just it should be documented that, say,
> kinfo.pid can be 0 if we race with the exiting task.
>
> Just in case, you can also use lock_task_sighand() || return -ESRCH,
> this way kinfo.*pid can't be zero. But I don't think this will buy too
> much, the task can exit right after pidfd_info() returns.
>
> Oleg.

I think what we should do is check if any of those fields was set to
0, and return ESRCH in that case. This way either we return a full set
of metadata that was correct at the time it was taken, or we provide
nothing and a clear error. We cannot solve the race as you mentioned,
but I think it is important to avoid providing incomplete information,
so that either the data is complete or nothing is given back. If the
information is complete but becomes stale later, that can happen and
it's ok.