linux-kernel - Re: [PATCH 0/2] Add framework for user controlled driver probes

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: <CAL_JsqKLT_H5jMnZYrpaZ246YmDtZHg7eQ6PJVp7sykVi3SG0A@mail.gmail.com>
Date: Fri, 27 Sep 2024 12:36:40 -0500
From: Rob Herring <robh@...nel.org>
To: Nayeemahmed Badebade <nayeemahmed.badebade@...y.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Greg KH <gregkh@...uxfoundation.org>, krzk+dt@...nel.org, 
	conor+dt@...nel.org, rafael@...nel.org, yoshihiro.toyama@...y.com, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 0/2] Add framework for user controlled driver probes

On Fri, Sep 27, 2024 at 10:04 AM Nayeemahmed Badebade
<nayeemahmed.badebade@...y.com> wrote:
>
> On Thu, Sep 26, 2024 at 02:34:26PM +0200, Krzysztof Kozlowski wrote:
> > On 26/09/2024 13:07, Nayeemahmed Badebade wrote:
> > >>
> > >>>> not required at the time of booting.
> > >>>> Example: drivers/pci/controller/dwc/pci-imx6.c
> > >>
> > >> Just this one?  I don't see anything obvious that can't turn that into a
> > >> module, have you tried?  What went wrong?
> > >>
> > >
> > > Yes we have tried building it as a module.
> > > This driver currently registers abort handler for pci using function
> > > hook_fault_code() on arm. This function is not exported and marked with __init
> > > tag. So we can't use it post boot.
> >
> > Then this is something to fix.
> >
> Thank you for the suggestion.
> As per discussion in below link, its mentioned that hooks should be static and
> should not change during runtime due to locking support not being there.
> So its not safe to export this function to use in modules as per the comments
> there.
> We would appreciate any suggestions you might have on any possible
> alternatives.
> > > Also from past attempt made to modularize this driver in community, we saw the
> > > hook is not safe to be used post boot.
> > > Reference:
> > >  https://lore.kernel.org/linux-arm-kernel/1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com/T/#m8995c6dcc40c54baef0665a7ee16d4209cb59655

The hook implementations have no interaction with the drivers other
than being installed by the driver. So move them out of the drivers
and the handler can be built-in with the driver as a module. For
example, see arch/arm/mach-bcm/bcm_5301x.c. Could possibly combine
some implementations. I haven't figured out why imx6 checks 2
different instructions while keystone only handles one. But imx6's
implementation being a superset should work for keystone perhaps.

Rob