Date:   Thu, 13 Apr 2017 09:08:37 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Michał Kępień <kernel@...pniu.pl>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Len Brown <len.brown@...el.com>,
        Pali Rohár <pali.rohar@...il.com>,
        Corentin Chary <corentin.chary@...il.com>,
        Mario Limonciello <Mario_Limonciello@...l.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        platform-driver-x86@...r.kernel.org,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: RFC: WMI Enhancements

On Thu, Apr 13, 2017 at 08:32:48AM -0700, Andy Lutomirski wrote:
> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@...pniu.pl> wrote:
> >> Hi All,
> >>
> >> There are a few parallel efforts involving the Windows Management
> >> Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have a round of
> >> discussion among those of you that have been involved in this space before we
> >> decide on a direction.
> >>
> >> The WMI support in the kernel today fairly narrowly supports a handful of
> >> systems. Andy L. has a work-in-progress series [2] which converts wmi into a
> >> platform device and a proper bus, providing devices for dependent drivers to
> >> bind to, and a mechanism for sibling devices to communicate with each other.
> >> I've reviewed the series and feel like the approach is sound, I plan to carry
> >> this series forward and merge it (with Andy L's permission).
> >>
> >> Are there any objections to this?
> >
> > Back in January 2016, I sent Andy a few minor comments about this
> > series.  A year later, I offered to iron out the remaining issues and
> > resubmit the series in Andy's name when I find the time.  Sadly, things
> > have changed a bit for me since that time and it is unlikely that I will
> > be able to deliver, for which I am sorry.
> >
> > However, browsing Andy's branch I see that most issues have been
> > resolved, though I think some of my remarks [1] have either been missed
> > or silently refuted :)
> >
> > Anyway, I also like this approach and I think this series is a valuable
> > cleanup.
> 
> Me too :)
> 
> >> In Windows, applications interact with WMI more or less directly. We don't do
> >> this in Linux currently, although it has been discussed in the past [3]. Some
> >> vendors will work around this by performing SMI/SMM, which is inefficient at
> >> best. Exposing WMI methods to userspace would bring parity to WMI for Linux and
> >> Windows.
> >>
> >> There are two principal concerns I'd appreciate your thoughts on:
> >>
> >> a) As an undiscoverable interface (you need to know the method signatures ahead
> >> of time), universally exposing every WMI "device" to userspace seems like "a bad
> >> idea" from a security and stability perspective. While access would certainly be
> >> privileged, it seems more prudent to make this exposure opt-in. We also handle
> >> some of this with kernel drivers and exposing those "devices" to userspace would
> >> enable userspace and the kernel to fight over control. So - if we expose WMI
> >> devices to userspace, I believe this should be done on a case by case basis,
> >> opting in, and not by default as part of the WMI driver (although it can provide
> >> the mechanism for a sub-driver to use), and possibly a devmode to do so by
> >> default.
> 
> I agree.  I don't want too see gnome-whatever-widget talking directly
> to WMI and confusing the kernel driver for the same thing.
> 
> >> Secondarily, Andy L created a simple driver to expose the MOF buffer [2] to
> >> userspace which could be consumed by a userspace tool to create sources for an
> >> interface to the exposed WMI methods.
> >
> > +1 for the idea, it makes figuring out what the firmware actually
> > exposes through WMI a bit easier.  After skimming through the driver's
> > code, I would only recommend to review the included headers
> > (linux/input/sparse-keymap.h, linux/dmi.h and acpi/video.h all seem
> > redundant to me).
> >
> > What we still need, though, is an open source version of wmiofck.exe.  I
> > am unaware of anything like that existing and installing the Windows
> > Driver Kit just to run one command which spits out a single *.h file is
> > not something I would describe as convenient (been there).
> 
> I haven't tried to see whether they do what's needed, but there's
> OpenWBEM and OpenPegasus.
> 
> Anyway, if such a tool exists, it would be handy to expose the binary
> MOF data to userspace so the tool could be used to help get WMI
> working on new platforms.
> 

Looking into what exists and what it might take to write a new tool is on my
todo list as a second priority to sorting out the WMI userspace mechanism issue.
Thanks for the pointers.

-- 
Darren Hart
VMware Open Source Technology Center

Powered by blists - more mailing lists