linux-kernel - RE: [PATCH v4 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5a114243f6844133a89d060347d5d390@ausx13mpc120.AMER.DELL.COM>
Date:   Thu, 5 Oct 2017 14:47:15 +0000
From:   <Mario.Limonciello@...l.com>
To:     <dvhart@...radead.org>
CC:     <andy.shevchenko@...il.com>, <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <luto@...nel.org>,
        <quasisec@...gle.com>, <pali.rohar@...il.com>, <rjw@...ysocki.net>,
        <mjg59@...gle.com>, <hch@....de>, <greg@...ah.com>
Subject: RE: [PATCH v4 05/14] platform/x86: dell-wmi-descriptor: split WMI
 descriptor into it's own driver

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@...radead.org]
> Sent: Thursday, October 5, 2017 9:15 AM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: andy.shevchenko@...il.com; linux-kernel@...r.kernel.org; platform-
> driver-x86@...r.kernel.org; luto@...nel.org; quasisec@...gle.com;
> pali.rohar@...il.com; rjw@...ysocki.net; mjg59@...gle.com; hch@....de;
> greg@...ah.com
> Subject: Re: [PATCH v4 05/14] platform/x86: dell-wmi-descriptor: split WMI
> descriptor into it's own driver
> 
> On Thu, Oct 05, 2017 at 01:59:36PM +0000, Mario.Limonciello@...l.com wrote:
> > > -----Original Message-----
> > > From: Andy Shevchenko [mailto:andy.shevchenko@...il.com]
> > > Sent: Thursday, October 5, 2017 3:48 AM
> > > To: Darren Hart <dvhart@...radead.org>
> > > Cc: Limonciello, Mario <Mario_Limonciello@...l.com>; LKML <linux-
> > > kernel@...r.kernel.org>; Platform Driver <platform-driver-
> > > x86@...r.kernel.org>; Andy Lutomirski <luto@...nel.org>;
> > > quasisec@...gle.com; Pali Rohár <pali.rohar@...il.com>; Rafael J. Wysocki
> > > <rjw@...ysocki.net>; mjg59@...gle.com; Christoph Hellwig <hch@....de>;
> > > Greg KH <greg@...ah.com>
> > > Subject: Re: [PATCH v4 05/14] platform/x86: dell-wmi-descriptor: split WMI
> > > descriptor into it's own driver
> > >
> > > On Thu, Oct 5, 2017 at 10:11 AM, Darren Hart <dvhart@...radead.org> wrote:
> > > > On Thu, Oct 05, 2017 at 08:29:10AM +0300, Andy Shevchenko wrote:
> > > >> On Thu, Oct 5, 2017 at 4:09 AM, Darren Hart <dvhart@...radead.org>
> wrote:
> > >
> > > >> > You'll want to add something like:
> > > >> >
> > > >> > #ifdef CONFIG_DELL_WMI_DESCRIPTOR_MODULE
> > > >> >         if (request_module("dell_wmi_descriptor"))
> > > >> >                 /* FAIL */
> > > >> > #endif
> > > >> >
> > > >> > During init.
> > > >>
> > > >> I don't think #ifdef is needed.
> > > >
> > > > Without the ifdef, we can't distinguish between request_module failing
> > > > to load the module because it isn't available and because it is
> > > > built-in.
> > > >
> > > >>
> > > >> We may just request module.
> > > >>
> > > >> But looking in the code it seems that we simple need to select that
> > > >> module. No request_module will be needed.
> > > >
> > > > The select will ensure the module is built, but there is not guarantee
> > > > to module load order. The intent of the above is to ensure the symbols
> > > > from the required module are loaded.
> > > >
> > > >> Did I miss something?
> > > >
> > > > Or I did :-) Is there something about this module which ensures
> > > > dell_wmi_descriptor is loaded first?
> > >
> > > If there is an optional *run-time* dependency we need to use somelike
> > > request_module(). For example, this is the case for idma64
> > > (drivers/dma) vs intel-lpss (drivers/mfd).
> > >
> > > If it's mandatory run-time dependency, then we need to add stubs to
> > > the header and select the callee's module in Kconfig.
> > >
> > > In case they are both modules, depmod keeps an ordering.
> > >
> > > So, the corner case here is when the caller is builtin while callee is module.
> > >
> > > This is a bit tricky to add to Kconfig (we also have such cases
> > > between I2C DesignWare and acpi_lpss AFAIR).
> > >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> >
> > So I believe it should be a mandatory runtime dependency due to needing
> > the symbol dell_wmi_get_interface_version.  Depmod should be handling
> > this then no?
> 
> This was nagging me all night, and I was thinking the last time I had to
> use this it was indeed a runtime dependency. Sorry for the noise on
> this.
> 
> The kconfig needs to be setup such that dell-wmi-descriptor cannot be a
> module if the dependent drivers are modules.
> 
> --
> Darren Hart
> VMware Open Source Technology Center

Even if the others are modules shouldn't module ordering from depmod still DTRT?
You still won't be able to load dell-wmi.ko until dell-wmi-descriptor.ko was loaded.