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: <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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ