linux-kernel - Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

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: <20170927165936.GF23572@fury>
Date:   Wed, 27 Sep 2017 09:59:36 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Mario.Limonciello@...l.com
Cc:     andy.shevchenko@...il.com, pali.rohar@...il.com,
        linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        quasisec@...gle.com
Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
 device for userspace

On Mon, Sep 25, 2017 at 05:46:54PM +0000, Mario.Limonciello@...l.com wrote:
> > -----Original Message-----
> > From: Andy Shevchenko [mailto:andy.shevchenko@...il.com]
> > Sent: Monday, September 25, 2017 12:58 PM
> > To: Pali Rohár <pali.rohar@...il.com>
> > Cc: Limonciello, Mario <Mario_Limonciello@...l.com>; dvhart@...radead.org;
> > LKML <linux-kernel@...r.kernel.org>; Platform Driver <platform-driver-
> > x86@...r.kernel.org>; quasisec@...gle.com
> > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> > device for userspace
> > 
> > On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@...il.com> wrote:
> > > On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
> > >> This userspace character device will be used to perform SMBIOS calls
> > >> from any applications sending a properly formatted 4k calling interface
> > >> buffer.
> > >>
> > >> This character device is intended to deprecate the dcdbas kernel module
> > >> and the interface that it provides to userspace.
> > >>
> > >> It's important for the driver to provide a R/W ioctl to ensure that
> > >> two competing userspace processes don't race to provide or read each
> > >> others data.
> > 
> > >> +What:                /dev/wmi-dell-wmi-smbios
> > >
> > > What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
> > > related and I think userspace does not have to care if it is via WMI or
> > > direct SMM mode... Important is that it provides character device for
> > > SMBIOS API and not how it is implemented.

I agree with this point, the implementation (WMI under the covers) is
not relevant. That said, this is an example of exposing WMI
functionality to userspace, and I DO NOT want to have a naming
discussion for every single WMI GUID that we choose to expose.

> > >
> > > Anyway, Darren, Andy, do we have some convention for naming platform
> > > character devices?
> > 
> > For me, looking to this case, seems better to expose a folder like
> > /dev/smbios/
> > with actual vendor device nodes inside like
> > /dev/smbios/dell
> 
> I disagree with this.  Dell exposes smbios calling in this kernel interface but
> other vendor drivers may also expose different methods for character devices
> that are not SMBIOS.
> 
> I'm envisioning that this is just the first kernel module that will use a WMI
> character device to userspace.  That's why I wanted to use a generic namespace.
> 
> I would say it could be /dev/wmi-$GUID or /dev/wmi/$driver-$GUID if you want 
> something more generic.
> As long as it's discovereable from uevent that's fine to me.
> 
> > 
> > Darren?

I would like to see an automated and definiitive way to export WMI
GUIDs. Something we can look at, compare to a set of rules, and say
yay/nay. From that perspective, I like Mario's general proposal. It is
not clear to me if the $driver- prefix adds any value though - would we
ever have need of DRIVER_X-GUID_A and DRIVER_Y-GUID_A ??? I'm thinking
not.

/dev/wmi/$GUID

-- 
Darren Hart
VMware Open Source Technology Center