linux-kernel - Re: [PATCH 0/8] gpiolib: add an ioctl() for monitoring line status changes

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: <CACRpkdZ6e0GaE9KBJ1-E+cS_KnPY-EKLNxJFqjArr28hYMQqOg@mail.gmail.com>
Date:   Fri, 29 Nov 2019 11:04:22 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Bartosz Golaszewski <brgl@...ev.pl>
Cc:     Kent Gibson <warthog618@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 0/8] gpiolib: add an ioctl() for monitoring line status changes

On Wed, Nov 27, 2019 at 2:35 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:

> This series adds a new ioctl() that allows user-space to retrieve a
> file-descriptor which can then be polled for events emitted by the kernel
> when the line is requested, released or its status changed. This of course
> doesn't require the line to be requested. Multiple user-space processes
> can watch the same lines.

So if I understand correctly all the series do is expose metadata about
all GPIO lines to userspace?

I think up until now the use case assumptions have been:

- The kernel will pick off some GPIO lines, mostly during boot but
  occasionally at runtime (by users such as kernel modules or
  hotlugged devices).

- Userspace will pick some lines from those that are available,
  after the kernel picked those it wants. If it tries to pick one of
  those that the kernel already picked, the request will be denied.

The assumption (at least in my head) was that the GPIOs the
kernel picks will not be a very dynamic business.

So this appears to be dealing with this very dynamic business.

Is the *main* use case different userspace processes trying
to use the same pins and getting denied? Because in that
case we might be putting a bit too much userspace plumbing
into the kernel and we need to think about that for a while.
(Binder and kdbus etc comes to mind.)

So there is some feature growth happening here and I want
to be aware of the whole picture.

On a side track:

There is a bit about policy that needs to happen here I suppose,
like for example what if the kernel actually wants one of the
lines that userspace has picked? Should userspace be kicked
out and kernel get what it wants? (Arguably yes.)

Yours,
Linus Walleij