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: <ZvVAiVBlBjkMhHMY@NAB-HP-ProDesk-600sony.com>
Date: Thu, 26 Sep 2024 16:37:53 +0530
From: Nayeemahmed Badebade <nayeemahmed.badebade@...y.com>
To: Greg KH <gregkh@...uxfoundation.org>,
        Krzysztof Kozlowski <krzk@...nel.org>
Cc: robh@...nel.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

Hi,

Sorry for the delay in our response.
Please find our reply to your comments:

On Tue, Sep 17, 2024 at 11:21:32AM +0200, Greg KH wrote:
> On Tue, Sep 17, 2024 at 11:03:14AM +0200, Krzysztof Kozlowski wrote:
> > On 17/09/2024 11:06, Nayeemahmed Badebade wrote:
> > > Hi Greg,
> > > 
> > > Thank you for taking the time to check our patch and provide
> > > valuable feedback. We appreciate your comments/suggestions.
> > > 
> > > Please find our reply to your comments.
> > > 
> > > On Fri, Sep 13, 2024 at 06:36:38AM +0200, Greg KH wrote:
> > >> On Wed, Sep 11, 2024 at 07:53:17PM +0530, Nayeemahmed Badebade wrote:
> > >>> Hi,
> > >>
> > >> If Rob hadn't responded, I wouldn't have noticed these as they ended up
> > >> in spam for some reason.  You might want to check your email settings...
> > >>
> > > 
> > > I have ensured standard settings which we have been using are used this
> > > time, let me know if this email is received properly.
> > > 
> > >>> This patch series introduces a new framework in the form of a driver
> > >>> probe-control, aimed at addressing the need for deferring the probes
> > >>> from built-in drivers in kernels where modules are not used.
> > >>
> > >> Wait, why?
> > >>
> > > 
> > > We have a scenario where a driver cannot be built as a module and ends up
> > > as a built-in driver. We don't want to probe this driver during boot as its
> > 
> > Fix this instead.
> 
> Agreed, that should be much simpler to do instead of adding core driver
> code that will affect all drivers/devices because just one driver
> doesn't seem to be able to be fixed?
> 
> What driver is this that is causing the problem?
> 
> > > 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.
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

We will further check this.
Thank you for your feedback.

Regards,
Nayeem