linux-kernel - Re: [PATCH v2 0/2] gpio-cdev: Release IRQ used by gpio-cdev on gpio chip removal

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: <CACRpkdYWDzu+VMQOYO_Sh1NM2ei=VRC-0df4teAZjirfrTB67A@mail.gmail.com>
Date: Fri, 1 Mar 2024 21:15:32 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Herve Codina <herve.codina@...tlin.com>, Kent Gibson <warthog618@...il.com>, 
	Saravana Kannan <saravanak@...gle.com>, linux-gpio@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Luca Ceresoli <luca.ceresoli@...tlin.com>, 
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v2 0/2] gpio-cdev: Release IRQ used by gpio-cdev on gpio
 chip removal

On Fri, Mar 1, 2024 at 8:21 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:

> Agreed and the big picture - just like with the reason behind the SRCU
> rework - is the fact that even static GPIO chips defined in ACPI or DT
> can be unbound. Unless you want to make the decision that we
> arbitrarily suppress_bind_attrs for all GPIO chips which I don't think
> you do.
>
> I have shown in the discussion under the previous iteration that a
> static GPIO chip defined in DT that is also marked as an
> interrupt-controller may have interrupts requested directly from its
> irq domain bypassing the .to_irq() callback. As long as this GPIO chip
> may be unbound (and we do not restrict this) it means the splat
> mentioned here can be triggered from user-space with a simple rmmod
> because a requested irq does not increase the module reference count
> nor do device links seem to work for interrupts not associated with a
> struct device explicitly.
>
> I DO want to fix it, don't get me wrong. I don't want to just leave it
> like this, especially since we've made so much progress with
> hotpluggability recently. I just don't believe this is the right fix,
> I will try to come up with a solution that addresses the issue
> globally.

OK I trust you to come up with something better for sure!

With regards to the ability to unbind/rebind drivers from sysfs, true.
I have heard about that as a counterargument to many things.

The problem is that I have never heard about a user unbinding/binding
a driver from sysfs for anything but debugging a drivers ability to
bind/unbind. Partly I feel that thing should just be moved
to debugfs given the usecase and because it just looks like a way for
attackers to provoke crashes given how some drivers look.

Yours,
Linus Walleij