linux-kernel - RE: [PATCH v2 12/14] 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: <fd379d7e9fd447a785be636fb5c30860@ausx13mpc120.AMER.DELL.COM>
Date:   Tue, 26 Sep 2017 20:16:48 +0000
From:   <Mario.Limonciello@...l.com>
To:     <pali.rohar@...il.com>
CC:     <dvhart@...radead.org>, <andy.shevchenko@...il.com>,
        <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <quasisec@...gle.com>
Subject: RE: [PATCH v2 12/14] platform/x86: dell-wmi-smbios: introduce
 character device for userspace

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@...il.com]
> Sent: Tuesday, September 26, 2017 4:10 PM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: dvhart@...radead.org; Andy Shevchenko <andy.shevchenko@...il.com>;
> LKML <linux-kernel@...r.kernel.org>; platform-driver-x86@...r.kernel.org;
> quasisec@...gle.com
> Subject: Re: [PATCH v2 12/14] platform/x86: dell-wmi-smbios: introduce character
> device for userspace
> 
> On Tuesday 26 September 2017 20:50:10 Mario Limonciello wrote:
> > This userspace character device will be used to perform SMBIOS calls
> > from any applications.
> >
> > It contains 3 operating IOCTL's
> > 1) sending a properly formatted 4k calling interface buffer.
> > 2) Querying number of tokens in the given system
> > 3) Copying the status of all these tokens to a properly formatted
> >    userspace 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.
> >
> > The character device will only be created if the WMI interface was
> > found.
> >
> > The API for interacting with this interface is defined in
> > documentation as well as a uapi header provides the format of the
> > structures.
> >
> > Signed-off-by: Mario Limonciello <mario.limonciello@...l.com>
> > ---
> >  Documentation/ABI/testing/dell-wmi-smbios |  10 +++
> >  drivers/platform/x86/dell-wmi-smbios.c    | 110
> > +++++++++++++++++++++++++++---
> > drivers/platform/x86/dell-wmi-smbios.h    |  28 +-------
> >  include/uapi/linux/dell-wmi-smbios.h      |  55 +++++++++++++++
> >  4 files changed, 165 insertions(+), 38 deletions(-)
> >  create mode 100644 Documentation/ABI/testing/dell-wmi-smbios
> >  create mode 100644 include/uapi/linux/dell-wmi-smbios.h
> >
> > diff --git a/Documentation/ABI/testing/dell-wmi-smbios
> > b/Documentation/ABI/testing/dell-wmi-smbios new file mode 100644
> > index 000000000000..8ec98e9b7b34
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/dell-wmi-smbios
> > @@ -0,0 +1,10 @@
> > +What:		/dev/wmi-dell-wmi-smbios
> > +Date:		October 2017
> > +KernelVersion:	4.15
> > +Contact:	"Mario Limonciello" <mario.limonciello@...l.com>
> > +Description:
> > +		Perform SMBIOS calls on supported Dell machines.
> > +		through the Dell ACPI-WMI interface.
> > +
> > +		IOCTL's and buffer formats are defined in:
> > +		<uapi/linux/dell-wmi-smbios.h>
> 
> Should be "wmi" part of device name, even if whole driver work without
> WMI?

Well actually the driver won't create a character device unless WMI is
used.  Exposing a character device for non-WMI is just duplicating dcdbas
at another endpoint without any security advantage.

> 
> I think that "wmi" should be part of device name only if it is related
> to WMI bus functions, and not in case when it exports some vendor (Dell)
> specific API which may be implemented via WMI.
> 
> E.g. we have /dev/i2c-* for raw access to i2c devices. But we do not
> have /dev/i2c-something for e.g. RTC device connected via i2c...

I see what you mean here, but I think we need Darren and Andy to weigh
in here.  

The character device does use WMI bus methods (wmi_evaluate_method).
The primary reason to create with wmi in the name is to show that the character 
devices are supposed to be created and managed by the WMI bus.  Vendor
drivers should not create their "own".  In my mind this will be especially relevant
once WMI bus can interpret MOF and create a set of mappings for attributes
defined in MOF.