linux-kernel - Re: [PATCH v1] iio: trigger: warn about non-registered iio trigger getting attempt

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: <20220601180326.3b6v4joykv5dryzm@CAB-WSD-L081021.sigma.sbrf.ru>
Date:   Wed, 1 Jun 2022 18:03:15 +0000
From:   Dmitry Rokosov <DDRokosov@...rdevices.ru>
To:     Nuno Sá <noname.nuno@...il.com>,
        "jic23@...nel.org" <jic23@...nel.org>
CC:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        kernel <kernel@...rdevices.ru>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] iio: trigger: warn about non-registered iio trigger
 getting attempt

Jonathan, Nuno,

I've sent RFC patch with trig->owner pointer initialization moval from
register() to allocate() stage as Nuno suggested before:

https://lore.kernel.org/linux-iio/20220601174837.20292-1-ddrokosov@sberdevices.ru/

Please review if possible and share your thoughts.

On Wed, Jun 01, 2022 at 03:09:03PM +0200, Nuno Sá wrote:
> On Wed, 2022-06-01 at 10:33 +0000, Dmitry Rokosov wrote:
> > Hi Nuno,
> > 
> > Thank you for comments!
> > 
> > On Wed, Jun 01, 2022 at 10:47:54AM +0200, Nuno Sá wrote:
> > > On Tue, 2022-05-31 at 18:57 +0000, Dmitry Rokosov wrote:
> > > > Hi Jonathan,
> > > > 
> > > > I have one question about a cases when trigger owner is builtin
> > > > module.
> > > > In the such cases trig->owner == null, because THIS_MODULE equals
> > > > to
> > > > null. How do you think, should we take into account such
> > > > situations?
> > > > 
> > > > IMHO we have to take in and save this information to trig_info
> > > > during
> > > > trigger allocation call. For example we can check THIS_MODULE
> > > > from
> > > > the
> > > 
> > > Hmmm, If we were to do something during iio_trigger_alloc(), we
> > > would
> > > rather assign already THIS_MODULE to owner and we would not need
> > > this
> > > WARN(). I mean, if someone calls iio_trigger_get() before
> > > allocating
> > > it, it will have bigger problems :).
> > > 
> > 
> > You are right, non-allocated pointer dereference is much bigger
> > problem :)
> > 
> > > I think this could actually be something reasonable...
> > 
> > I think it could be a good solution, but it's required a lot of
> > changes
> > in the IIO drivers code, because if we assign trig->owner from
> > iio_trigger_alloc(), we do not need this_mod parameter in the
> > iio_trigger_register() iface and its wrappers.
> > So it means to make it workable we must:
> >     - rework iio_trigger_alloc()
> >     - redesign iio_trigger_register() iface and its wrappers
> >     - correct iio_trigger_register() call from all IIO drivers
> > 
> > I suppose we need to wait for Jonathan's comments here...
> > 
> 
> I think we could actually get this done without having to change all
> the drivers. Note on how iio_trigger_register() passes THIS_MODULE to
> the internal API. We could also use macros in the alloc function in a
> way that only internal functions would need to be changed. But it all
> depends on whether or not Jonathan wants this moved...
> 
> - Nuno Sá

-- 
Thank you,
Dmitry