Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1622607 > unrolled thread

RFC: WMI Enhancements

Back to article view | Back to linux.kernel

Contents

  RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 01:10 +0200
    Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-13 09:40 +0200
      Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 19:00 +0200
        RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 22:40 +0200
          Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-14 02:00 +0200
            RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-14 19:50 +0200
              Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-14 20:30 +0200
                RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-14 21:10 +0200
    Re: RFC: WMI Enhancements Michał Kępień <kernel@kempniu.pl> - 2017-04-13 09:40 +0200
      RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 15:50 +0200
        Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-13 16:00 +0200
          Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 17:40 +0200
            RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 18:00 +0200
              Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 18:10 +0200
          RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 17:50 +0200
            Re: RFC: WMI Enhancements Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2017-04-18 12:00 +0200
              RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-18 16:10 +0200
      Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 17:40 +0200
        Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 17:50 +0200
          Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 18:20 +0200
        Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-13 17:50 +0200
        Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 18:00 +0200
          RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 19:00 +0200
            Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 19:10 +0200
              Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 19:50 +0200
                RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 20:00 +0200
              RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 19:50 +0200
                Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-18 10:00 +0200
                  Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-18 19:00 +0200
                    Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-18 21:30 +0200
        RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 18:00 +0200
          Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 19:10 +0200
            Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 19:40 +0200
              RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 19:50 +0200
        Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 18:10 +0200
    Re: RFC: WMI Enhancements "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-04-15 01:00 +0200
      Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-15 01:10 +0200
        Re: RFC: WMI Enhancements Andy Lutomirski <luto@amacapital.net> - 2017-04-18 00:10 +0200
          Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-18 01:20 +0200
            Re: RFC: WMI Enhancements "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-04-18 15:20 +0200
              Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-18 18:40 +0200
                Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-18 21:30 +0200
                  Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-19 00:50 +0200
                    Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-19 10:00 +0200
                      RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-19 18:40 +0200
                        Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-19 19:00 +0200
                          RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-19 19:30 +0200
                            Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-20 15:20 +0200
                              Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-20 22:50 +0200
                          Re: RFC: WMI Enhancements Christoph Hellwig <hch@infradead.org> - 2017-04-20 16:20 +0200
                Re: RFC: WMI Enhancements "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-18 23:20 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1625435

On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
> On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart <dvhart@infradead.org> wrote:
> > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
> > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart 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?
> > > >> >
> > > >> > 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.
> > > >>
> > > >> A couple of loose thoughts here.
> > > >>
> > > >> In principle there could be a "generic default WMI driver" or similar that would
> > > >> "claim" all WMI "devices" that have not been "claimed" by anyone else and would
> > > >> simply expose them to user space somehow (e.g. using a chardev interface).
> > > >>
> > > >> Then, depending on how that thing is implemented, opt-in etc should be possible
> > > >> too.
> > > >>
> > > >
> > > > I think we agree this would be an ideal approach.
> > > >
> > > > As we look into this more, it is becoming clear that the necessary functionality
> > > > is not nicely divided into GUIDs for what is necessary in userspace and what is
> > > > handled in the kernel. A single WMI METHOD GUID may be needed by userspace for
> > > > certain functionality, while the kernel drivers may use it for something else.
> > > >
> > > > :-(
> > > >
> > > > The input to a WMI method is just a buffer, so it is very free form. One
> > > > approach Mario has mentioned was to audit the user space WMI METHOD calls in the
> > > > kernel platform drivers and reject those calls with arguments matching those
> > > > issued by the kernel driver. This is likely to be complex and error prone in my
> > > > opinion. However, I have not yet thought of another means to meet the
> > > > requirement of having disjoint feature sets for userspace and kernel space via a
> > > > mechanism that was effectively designed to be used solely from user space with
> > > > vendor defined method signatures.
> > > >
> > > > Next step is to look at just how complex it would be to audit the method calls
> > > > the kernel currently uses.
> > > 
> > > I'm wondering whether it's really worth it.  We already allow doing
> > > darned near anything using dcdbas.  Maybe the world won't end if we
> > > expose a complete-ish ioctl interface to WMI.
> 
> I guess the world wouldn't end then (it has not ended for far more serious
> reasons so far after all), but this also doesn't feel entirely right.
> 
> For one, if something is used inside of the kernel (by drivers etc), then
> allowing user space to use the same thing directly is a recipe for unsupportable
> mess IMO.

I don't disagree. Unforuntately, the mechanism wasn't designed for this kind of
mixed usage from what I can determine, so it doesn't lend itself to separation.
We could kick out all the WMI drivers and encourage vendor/platform specific
system daemons which read WMI and injected events and configured LEDs through
sysfs, thus eliminating the user/kernel conflict - but it would only leave us
with the problem of multiple userspace daemons competing for the same WMI
METHODs -- and yeah, nobody's going for that :-D

> 
> > > Also, dcdbas is, to put it mildly, a bit ridiculous.  It seems to be a
> > > seriously awkward sysfs interface that allows you to, drumroll please,
> > > issue outb and inb instructions.  It doesn't even check that it's
> > > running on a Dell system.  It might be nice to deprecate it some day
> > > in favor of a real interface.  I'd consider a low-level WMI ioctl
> > > interface to be a vast improvement.
> > > 
> > 
> > I've been reluctantly arriving here as well. Given that every WMI interface will
> > be vendor specific, and non-discoverable, it seems unlikely developers will
> > eagerly duplicate kernel functionality in user-space. And if they do, it will
> > affect very few platforms.
> > 
> > I still think it makes sense to only expose a WMI interface by default on some
> > matching criteria. It could be DMI related, but I'd like to know if the UID is
> > possible as well (it depends on how vendors use the UID, if consistently, not at
> > all, etc.) Otherwise, the interface would not be enabled unless the user
> > explicitly requests it via a module parameter or similar.
> 
> To me, that should be the bare minimum, but I really think that mutual exclusion
> between user space and the kernel needs to be ensured somehow when the
> interface is enabled too.
> 
> This looks similar to exposing _DSM functionality for certain device to user
> space where some functions of the _DSM in question are already in use by
> kernel code.  In that case I would think about an interface with a function
> granularity (so it would check the GUID and the function and possibly the
> ordering with respect to the other functions too before invoking the _DSM
> on behalf of user space).

This is also what I would consider to be ideal, but the mechanism doesn't lend
itself to that level of granularity. WMI methods are not guaranteed to be broken
up into sufficiently granular functionality that we can filter based on method
ID. We would most likely end up in the position of having to audit the input
buffer of every WMI call.

For example, we can filter things the ASUS WMI Keyboard Filter method, but
others are less specific, like Device Set, Bios Status, Device Status, Device
Policy, etc.

What we could do is make that the vendor's problem instead of the kernel's
problem. Consider:

* wmi.c adds method evaluation wrappers
* add a wmi evaluation mutex
* update *wmi.c drivers to use the new wrappers
* platform drivers (dell-wmi.c, asus-wmi.c, etc.) must explicitly request
  wmi.c to export the wmi chardev
* platform drivers must explicitly whitelist each method ID to be exported
  - they can automate this in a loop evaluating the wmi block if they wish
* platform drivers *may* register a wmi evaluation filter which allows them
  to audit the method id and input buffer to ensure it doesn't conflict with
  in-kernel usage (their usage).

I believe this is a reasonable compromise, and it places the burden on the
platform drivers, and therefor on the vendors (in the best case) or the
individual platform driver maintainers for less cooperative vendors. This
contains any resulting exposure to the platforms which explicitly request it.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1625568

[Multipart message — attachments visible in raw view] — view raw

On Tuesday 18 April 2017 18:33:25 Darren Hart wrote:
> On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
> > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart
> > > > <dvhart@infradead.org> wrote:
> > > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki
> > > > > wrote:
> > > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart 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?
> > > > >> > 
> > > > >> > 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.
> > > > >> 
> > > > >> A couple of loose thoughts here.
> > > > >> 
> > > > >> In principle there could be a "generic default WMI driver"
> > > > >> or similar that would "claim" all WMI "devices" that have
> > > > >> not been "claimed" by anyone else and would simply expose
> > > > >> them to user space somehow (e.g. using a chardev
> > > > >> interface).
> > > > >> 
> > > > >> Then, depending on how that thing is implemented, opt-in etc
> > > > >> should be possible too.
> > > > > 
> > > > > I think we agree this would be an ideal approach.
> > > > > 
> > > > > As we look into this more, it is becoming clear that the
> > > > > necessary functionality is not nicely divided into GUIDs for
> > > > > what is necessary in userspace and what is handled in the
> > > > > kernel. A single WMI METHOD GUID may be needed by userspace
> > > > > for certain functionality, while the kernel drivers may use
> > > > > it for something else.
> > > > > 
> > > > > :-(
> > > > > 
> > > > > The input to a WMI method is just a buffer, so it is very
> > > > > free form. One approach Mario has mentioned was to audit the
> > > > > user space WMI METHOD calls in the kernel platform drivers
> > > > > and reject those calls with arguments matching those issued
> > > > > by the kernel driver. This is likely to be complex and error
> > > > > prone in my opinion. However, I have not yet thought of
> > > > > another means to meet the requirement of having disjoint
> > > > > feature sets for userspace and kernel space via a mechanism
> > > > > that was effectively designed to be used solely from user
> > > > > space with vendor defined method signatures.
> > > > > 
> > > > > Next step is to look at just how complex it would be to audit
> > > > > the method calls the kernel currently uses.
> > > > 
> > > > I'm wondering whether it's really worth it.  We already allow
> > > > doing darned near anything using dcdbas.  Maybe the world
> > > > won't end if we expose a complete-ish ioctl interface to WMI.
> > 
> > I guess the world wouldn't end then (it has not ended for far more
> > serious reasons so far after all), but this also doesn't feel
> > entirely right.
> > 
> > For one, if something is used inside of the kernel (by drivers
> > etc), then allowing user space to use the same thing directly is a
> > recipe for unsupportable mess IMO.
> 
> I don't disagree. Unforuntately, the mechanism wasn't designed for
> this kind of mixed usage from what I can determine, so it doesn't
> lend itself to separation.

Yes, and this is reason why abstract generic interface has problems and 
cannot be really generic.

> We could kick out all the WMI drivers and
> encourage vendor/platform specific system daemons which read WMI and
> injected events and configured LEDs through sysfs, thus eliminating
> the user/kernel conflict - but it would only leave us with the
> problem of multiple userspace daemons competing for the same WMI
> METHODs -- and yeah, nobody's going for that :-D

IMO, this will only results in more problems as we already have and does 
not bring any value. Just anarchy, like in windows world.

> > > > Also, dcdbas is, to put it mildly, a bit ridiculous.  It seems
> > > > to be a seriously awkward sysfs interface that allows you to,
> > > > drumroll please, issue outb and inb instructions.  It doesn't
> > > > even check that it's running on a Dell system.  It might be
> > > > nice to deprecate it some day in favor of a real interface. 
> > > > I'd consider a low-level WMI ioctl interface to be a vast
> > > > improvement.
> > > 
> > > I've been reluctantly arriving here as well. Given that every WMI
> > > interface will be vendor specific, and non-discoverable, it
> > > seems unlikely developers will eagerly duplicate kernel
> > > functionality in user-space. And if they do, it will affect very
> > > few platforms.
> > > 
> > > I still think it makes sense to only expose a WMI interface by
> > > default on some matching criteria. It could be DMI related, but
> > > I'd like to know if the UID is possible as well (it depends on
> > > how vendors use the UID, if consistently, not at all, etc.)
> > > Otherwise, the interface would not be enabled unless the user
> > > explicitly requests it via a module parameter or similar.
> > 
> > To me, that should be the bare minimum, but I really think that
> > mutual exclusion between user space and the kernel needs to be
> > ensured somehow when the interface is enabled too.
> > 
> > This looks similar to exposing _DSM functionality for certain
> > device to user space where some functions of the _DSM in question
> > are already in use by kernel code.  In that case I would think
> > about an interface with a function granularity (so it would check
> > the GUID and the function and possibly the ordering with respect
> > to the other functions too before invoking the _DSM on behalf of
> > user space).
> 
> This is also what I would consider to be ideal, but the mechanism
> doesn't lend itself to that level of granularity. WMI methods are
> not guaranteed to be broken up into sufficiently granular
> functionality that we can filter based on method ID. We would most
> likely end up in the position of having to audit the input buffer of
> every WMI call.

And still, if write audit filters for every one existing wmi driver in 
kernel, there still audit filter can say to userspace that current 
request cannot be accepted and sent to firmware.

This would mean that userspace application would not be able to do ANY 
WMI method call (as e.g. on windows) and so for some vendors it can be 
useless.

And here I'm not sure, how hard would be to write those audit filters 
for all wmi kernel drivers and if it would be possible without wmi 
documentation of those vendor apis (which we do not have).

Potential vendors can decide based on above fact, that their userspace 
application rather rmmod wmi kernel driver for particular GUID (which 
release occupation of wmi device) and their userspace application starts 
working. And this is I think situation which is bad for kernel and we 
should prevent it.

> For example, we can filter things the ASUS WMI Keyboard Filter
> method, but others are less specific, like Device Set, Bios Status,
> Device Status, Device Policy, etc.
> 
> What we could do is make that the vendor's problem instead of the
> kernel's problem. Consider:
> 
> * wmi.c adds method evaluation wrappers
> * add a wmi evaluation mutex
> * update *wmi.c drivers to use the new wrappers
> * platform drivers (dell-wmi.c, asus-wmi.c, etc.) must explicitly
> request wmi.c to export the wmi chardev
> * platform drivers must explicitly whitelist each method ID to be
> exported - they can automate this in a loop evaluating the wmi block
> if they wish * platform drivers *may* register a wmi evaluation
> filter which allows them to audit the method id and input buffer to
> ensure it doesn't conflict with in-kernel usage (their usage).
> 
> I believe this is a reasonable compromise, and it places the burden
> on the platform drivers, and therefor on the vendors (in the best
> case) or the individual platform driver maintainers for less
> cooperative vendors. This contains any resulting exposure to the
> platforms which explicitly request it.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1625685

On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote:
> On Tuesday 18 April 2017 18:33:25 Darren Hart wrote:
> > On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
> > > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> > > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart
> > > > > <dvhart@infradead.org> wrote:
> > > > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki
> > > > > > wrote:
> > > > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart 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?
> > > > > >> > 
> > > > > >> > 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.
> > > > > >> 
> > > > > >> A couple of loose thoughts here.
> > > > > >> 
> > > > > >> In principle there could be a "generic default WMI driver"
> > > > > >> or similar that would "claim" all WMI "devices" that have
> > > > > >> not been "claimed" by anyone else and would simply expose
> > > > > >> them to user space somehow (e.g. using a chardev
> > > > > >> interface).
> > > > > >> 
> > > > > >> Then, depending on how that thing is implemented, opt-in etc
> > > > > >> should be possible too.
> > > > > > 
> > > > > > I think we agree this would be an ideal approach.
> > > > > > 
> > > > > > As we look into this more, it is becoming clear that the
> > > > > > necessary functionality is not nicely divided into GUIDs for
> > > > > > what is necessary in userspace and what is handled in the
> > > > > > kernel. A single WMI METHOD GUID may be needed by userspace
> > > > > > for certain functionality, while the kernel drivers may use
> > > > > > it for something else.
> > > > > > 
> > > > > > :-(
> > > > > > 
> > > > > > The input to a WMI method is just a buffer, so it is very
> > > > > > free form. One approach Mario has mentioned was to audit the
> > > > > > user space WMI METHOD calls in the kernel platform drivers
> > > > > > and reject those calls with arguments matching those issued
> > > > > > by the kernel driver. This is likely to be complex and error
> > > > > > prone in my opinion. However, I have not yet thought of
> > > > > > another means to meet the requirement of having disjoint
> > > > > > feature sets for userspace and kernel space via a mechanism
> > > > > > that was effectively designed to be used solely from user
> > > > > > space with vendor defined method signatures.
> > > > > > 
> > > > > > Next step is to look at just how complex it would be to audit
> > > > > > the method calls the kernel currently uses.
> > > > > 
> > > > > I'm wondering whether it's really worth it.  We already allow
> > > > > doing darned near anything using dcdbas.  Maybe the world
> > > > > won't end if we expose a complete-ish ioctl interface to WMI.
> > > 
> > > I guess the world wouldn't end then (it has not ended for far more
> > > serious reasons so far after all), but this also doesn't feel
> > > entirely right.
> > > 
> > > For one, if something is used inside of the kernel (by drivers
> > > etc), then allowing user space to use the same thing directly is a
> > > recipe for unsupportable mess IMO.
> > 
> > I don't disagree. Unforuntately, the mechanism wasn't designed for
> > this kind of mixed usage from what I can determine, so it doesn't
> > lend itself to separation.
> 
> Yes, and this is reason why abstract generic interface has problems and 
> cannot be really generic.
> 
> > We could kick out all the WMI drivers and
> > encourage vendor/platform specific system daemons which read WMI and
> > injected events and configured LEDs through sysfs, thus eliminating
> > the user/kernel conflict - but it would only leave us with the
> > problem of multiple userspace daemons competing for the same WMI
> > METHODs -- and yeah, nobody's going for that :-D
> 
> IMO, this will only results in more problems as we already have and does 
> not bring any value. Just anarchy, like in windows world.
> 
> > > > > Also, dcdbas is, to put it mildly, a bit ridiculous.  It seems
> > > > > to be a seriously awkward sysfs interface that allows you to,
> > > > > drumroll please, issue outb and inb instructions.  It doesn't
> > > > > even check that it's running on a Dell system.  It might be
> > > > > nice to deprecate it some day in favor of a real interface. 
> > > > > I'd consider a low-level WMI ioctl interface to be a vast
> > > > > improvement.
> > > > 
> > > > I've been reluctantly arriving here as well. Given that every WMI
> > > > interface will be vendor specific, and non-discoverable, it
> > > > seems unlikely developers will eagerly duplicate kernel
> > > > functionality in user-space. And if they do, it will affect very
> > > > few platforms.
> > > > 
> > > > I still think it makes sense to only expose a WMI interface by
> > > > default on some matching criteria. It could be DMI related, but
> > > > I'd like to know if the UID is possible as well (it depends on
> > > > how vendors use the UID, if consistently, not at all, etc.)
> > > > Otherwise, the interface would not be enabled unless the user
> > > > explicitly requests it via a module parameter or similar.
> > > 
> > > To me, that should be the bare minimum, but I really think that
> > > mutual exclusion between user space and the kernel needs to be
> > > ensured somehow when the interface is enabled too.
> > > 
> > > This looks similar to exposing _DSM functionality for certain
> > > device to user space where some functions of the _DSM in question
> > > are already in use by kernel code.  In that case I would think
> > > about an interface with a function granularity (so it would check
> > > the GUID and the function and possibly the ordering with respect
> > > to the other functions too before invoking the _DSM on behalf of
> > > user space).
> > 
> > This is also what I would consider to be ideal, but the mechanism
> > doesn't lend itself to that level of granularity. WMI methods are
> > not guaranteed to be broken up into sufficiently granular
> > functionality that we can filter based on method ID. We would most
> > likely end up in the position of having to audit the input buffer of
> > every WMI call.
> 
> And still, if write audit filters for every one existing wmi driver in 
> kernel, there still audit filter can say to userspace that current 
> request cannot be accepted and sent to firmware.

For the vast majority of platforms, the WMI interface would not be exported, and
we would not attempt to write audit filters. As a rule, I would expect this
effort to be triggered by a request from the vendor, and done only with their
explicit involvement after providing complete documentation of the WMI
interface.

However, we would expect those filters to deny as few calls as possible for the
platforms that choose to export the WMI interface to userspace.

For example, dell-wmi.c would be largely unaffected as the EVENT_GUID is not
interesting for userspace (per Mario) and would not be exported. The Descriptor
GUID should be safe to share with userspace, at least for the way we use it in
the kernel. Similar for dell-wmi-aio.c

For dell-wmi-led.c, we could most likely not export the GUID at all, but if we
did, we could choose to filter on device_id or command from the bios_args used
in the input buffer.

I don't think I've seen exactly what the WMI interface for the existing SMBIOS
stuff will look like, but we seem to have a fairly structured way of accessing it
today, which should allow us to filter out those specific usages (such as
rfkill). Additionally, the concern that userspace can make use of the same
mechanism as the kernel is where we are today with libsmbios.

With WMI filters, we could, for example, deny all DELL_SMBIOS_WMI GUID calls
equivalent to "class 17, select 11" (Wireless control), since that is handled
internally. Similarly for "4,11" (KBD ALS).

> 
> This would mean that userspace application would not be able to do ANY 
> WMI method call (as e.g. on windows) and so for some vendors it can be 
> useless.

We address this with more granular filters.

> And here I'm not sure, how hard would be to write those audit filters 
> for all wmi kernel drivers and if it would be possible without wmi 
> documentation of those vendor apis (which we do not have).

As above, we won't write them for every wmi kernel driver. Only for those
vendors which engage with us to do so.

> Potential vendors can decide based on above fact, that their userspace 
> application rather rmmod wmi kernel driver for particular GUID (which 
> release occupation of wmi device) and their userspace application starts 
> working. And this is I think situation which is bad for kernel and we 
> should prevent it.

I agree we would want to avoid this. As this is off by default and only enabled
/ implemented with the cooperation of the vendor in the first place, I suspect
this kind of antagonistic interaction is unlikely.

You previously mentioned doing a vendor specific interface. This was my initial
response as well, but it doesn't meet the intent of the WMI interface, nor the
needs of vendors like Dell. That is, it requires a priori knowledge of all
current and future interfaces, and/or the continued gating on the Linux kernel
in order to allow a new method/interface. Further, by creating these interfaces,
we become more tied to them, and they will grow over time, until they are a very
large set of mostly deprecated interfaces which we can't remove for legacy
reasons.

All that said, I appreciate the concerns you've raised and they mirror many of
my own. I don't think we can just say "no, Windows Management Instrumentation is
only accessible in Linux within the kernel" as that is ultimately contrary to
the purpose of the mechanism. With those concerns in mind, I proposed the
general approach below which affords considerable freedom for vendors to manage
their systems while retaining the right to deny access to the existing Linux
kernel drivers. At the same time, it provides a general purpose interface to
userspace which won't collect legacy code we have to maintain forever.

Thanks,

> 
> > For example, we can filter things the ASUS WMI Keyboard Filter
> > method, but others are less specific, like Device Set, Bios Status,
> > Device Status, Device Policy, etc.
> > 
> > What we could do is make that the vendor's problem instead of the
> > kernel's problem. Consider:
> > 
> > * wmi.c adds method evaluation wrappers
> > * add a wmi evaluation mutex
> > * update *wmi.c drivers to use the new wrappers
> > * platform drivers (dell-wmi.c, asus-wmi.c, etc.) must explicitly
> > request wmi.c to export the wmi chardev
> > * platform drivers must explicitly whitelist each method ID to be
> > exported - they can automate this in a loop evaluating the wmi block
> > if they wish * platform drivers *may* register a wmi evaluation
> > filter which allows them to audit the method id and input buffer to
> > ensure it doesn't conflict with in-kernel usage (their usage).
> > 
> > I believe this is a reasonable compromise, and it places the burden
> > on the platform drivers, and therefor on the vendors (in the best
> > case) or the individual platform driver maintainers for less
> > cooperative vendors. This contains any resulting exposure to the
> > platforms which explicitly request it.
> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com



-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1625892

On Tuesday 18 April 2017 15:49:31 Darren Hart wrote:
> On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote:
> > And still, if write audit filters for every one existing wmi driver in 
> > kernel, there still audit filter can say to userspace that current 
> > request cannot be accepted and sent to firmware.
> 
> For the vast majority of platforms, the WMI interface would not be exported, and
> we would not attempt to write audit filters. As a rule, I would expect this
> effort to be triggered by a request from the vendor, and done only with their
> explicit involvement after providing complete documentation of the WMI
> interface.

Ok, if WMI interface would be exported to userspace only after previous
communication with vendor, then this should be OK. It also means that we
need to maintain list of WMI GUIDs...

> However, we would expect those filters to deny as few calls as possible for the
> platforms that choose to export the WMI interface to userspace.

I expect that vendor would be communicate with kernel developers and
filters would be written with agreement with vendor. This seems OK.

> For example, dell-wmi.c would be largely unaffected as the EVENT_GUID is not
> interesting for userspace (per Mario) and would not be exported. The Descriptor
> GUID should be safe to share with userspace, at least for the way we use it in
> the kernel. Similar for dell-wmi-aio.c
> 
> For dell-wmi-led.c, we could most likely not export the GUID at all, but if we
> did, we could choose to filter on device_id or command from the bios_args used
> in the input buffer.
> 
> I don't think I've seen exactly what the WMI interface for the existing SMBIOS
> stuff will look like, but we seem to have a fairly structured way of accessing it
> today, which should allow us to filter out those specific usages (such as
> rfkill). Additionally, the concern that userspace can make use of the same
> mechanism as the kernel is where we are today with libsmbios.
> 
> With WMI filters, we could, for example, deny all DELL_SMBIOS_WMI GUID calls
> equivalent to "class 17, select 11" (Wireless control), since that is handled
> internally. Similarly for "4,11" (KBD ALS).
> 
> > 
> > This would mean that userspace application would not be able to do ANY 
> > WMI method call (as e.g. on windows) and so for some vendors it can be 
> > useless.
> 
> We address this with more granular filters.
> 
> > And here I'm not sure, how hard would be to write those audit filters 
> > for all wmi kernel drivers and if it would be possible without wmi 
> > documentation of those vendor apis (which we do not have).
> 
> As above, we won't write them for every wmi kernel driver. Only for those
> vendors which engage with us to do so.
> 
> > Potential vendors can decide based on above fact, that their userspace 
> > application rather rmmod wmi kernel driver for particular GUID (which 
> > release occupation of wmi device) and their userspace application starts 
> > working. And this is I think situation which is bad for kernel and we 
> > should prevent it.
> 
> I agree we would want to avoid this. As this is off by default and only enabled
> / implemented with the cooperation of the vendor in the first place, I suspect
> this kind of antagonistic interaction is unlikely.
> 
> You previously mentioned doing a vendor specific interface. This was my initial
> response as well, but it doesn't meet the intent of the WMI interface, nor the
> needs of vendors like Dell. That is, it requires a priori knowledge of all
> current and future interfaces, and/or the continued gating on the Linux kernel
> in order to allow a new method/interface. Further, by creating these interfaces,
> we become more tied to them, and they will grow over time, until they are a very
> large set of mostly deprecated interfaces which we can't remove for legacy
> reasons.

Benefit of vendor specific API is code de-duplication and having common
functions in one place. E.g. code for changing SMBIOS token does not
have to be implemented in both userspace and kernel, just in kernel.

Also handling generic API requests from userspace in kernel and then
pass them to firmware is a bit harder and less error prone. Also audit
filters would be less easier...

I still think that we do not have to export WMI as is to userspace and
personally I do not think it is the best solution even if Microsoft is
doing it...

But if we are unable to design such API and vendor (e.g. Dell) already
wants WMI API in userspace, then we probably should export it from them.

> All that said, I appreciate the concerns you've raised and they mirror many of
> my own. I don't think we can just say "no, Windows Management Instrumentation is
> only accessible in Linux within the kernel" as that is ultimately contrary to
> the purpose of the mechanism. With those concerns in mind, I proposed the
> general approach below which affords considerable freedom for vendors to manage
> their systems while retaining the right to deny access to the existing Linux
> kernel drivers. At the same time, it provides a general purpose interface to
> userspace which won't collect legacy code we have to maintain forever.

The main concern is that WMI is something like meta-API or RPC. In most
cases it would be needed to write "wrapper" code around to do call
needed functions or do something. It is needed to written in kernel
(e.g. for class drivers or for filters), but also vendor needs to
duplicate functionality in userspace. And this does not seems to be
ideal, probably it can be design-antipattern.

As wrote above, I'm fine with explicit whitelist of WMI GUIDs which will
be exported to userspace after communication with vendor.

One more thing: We should not provide new interface API/ABI between
kernel and userspace without some open source implementation of
userspace. This is IIRC some Linus's rule. And I'm not sure if vendors
are going to provide some userspace WMI implementations as open
source...

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1626495

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Wednesday, April 19, 2017 2:53 AM
> To: Darren Hart <dvhart@infradead.org>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; Andy Lutomirski
> <luto@amacapital.net>; Len Brown <len.brown@intel.com>; Corentin Chary
> <corentin.chary@gmail.com>; Limonciello, Mario <Mario_Limonciello@Dell.com>;
> Andy Lutomirski <luto@kernel.org>; Andy Shevchenko
> <andriy.shevchenko@linux.intel.com>; LKML <linux-kernel@vger.kernel.org>;
> platform-driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Tuesday 18 April 2017 15:49:31 Darren Hart wrote:
> > On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote:
> > > And still, if write audit filters for every one existing wmi driver in
> > > kernel, there still audit filter can say to userspace that current
> > > request cannot be accepted and sent to firmware.
> >
> > For the vast majority of platforms, the WMI interface would not be exported, and
> > we would not attempt to write audit filters. As a rule, I would expect this
> > effort to be triggered by a request from the vendor, and done only with their
> > explicit involvement after providing complete documentation of the WMI
> > interface.
> 
> Ok, if WMI interface would be exported to userspace only after previous
> communication with vendor, then this should be OK. It also means that we
> need to maintain list of WMI GUIDs...
> 
> > However, we would expect those filters to deny as few calls as possible for the
> > platforms that choose to export the WMI interface to userspace.
> 
> I expect that vendor would be communicate with kernel developers and
> filters would be written with agreement with vendor. This seems OK.
> 
> > For example, dell-wmi.c would be largely unaffected as the EVENT_GUID is not
> > interesting for userspace (per Mario) and would not be exported. The Descriptor
> > GUID should be safe to share with userspace, at least for the way we use it in
> > the kernel. Similar for dell-wmi-aio.c
> >
> > For dell-wmi-led.c, we could most likely not export the GUID at all, but if we
> > did, we could choose to filter on device_id or command from the bios_args used
> > in the input buffer.
> >
> > I don't think I've seen exactly what the WMI interface for the existing SMBIOS
> > stuff will look like, but we seem to have a fairly structured way of accessing it
> > today, which should allow us to filter out those specific usages (such as
> > rfkill). Additionally, the concern that userspace can make use of the same
> > mechanism as the kernel is where we are today with libsmbios.
> >
> > With WMI filters, we could, for example, deny all DELL_SMBIOS_WMI GUID calls
> > equivalent to "class 17, select 11" (Wireless control), since that is handled
> > internally. Similarly for "4,11" (KBD ALS).
> >
> > >
> > > This would mean that userspace application would not be able to do ANY
> > > WMI method call (as e.g. on windows) and so for some vendors it can be
> > > useless.
> >
> > We address this with more granular filters.
> >
> > > And here I'm not sure, how hard would be to write those audit filters
> > > for all wmi kernel drivers and if it would be possible without wmi
> > > documentation of those vendor apis (which we do not have).
> >
> > As above, we won't write them for every wmi kernel driver. Only for those
> > vendors which engage with us to do so.
> >
> > > Potential vendors can decide based on above fact, that their userspace
> > > application rather rmmod wmi kernel driver for particular GUID (which
> > > release occupation of wmi device) and their userspace application starts
> > > working. And this is I think situation which is bad for kernel and we
> > > should prevent it.
> >
> > I agree we would want to avoid this. As this is off by default and only enabled
> > / implemented with the cooperation of the vendor in the first place, I suspect
> > this kind of antagonistic interaction is unlikely.
> >
> > You previously mentioned doing a vendor specific interface. This was my initial
> > response as well, but it doesn't meet the intent of the WMI interface, nor the
> > needs of vendors like Dell. That is, it requires a priori knowledge of all
> > current and future interfaces, and/or the continued gating on the Linux kernel
> > in order to allow a new method/interface. Further, by creating these interfaces,
> > we become more tied to them, and they will grow over time, until they are a very
> > large set of mostly deprecated interfaces which we can't remove for legacy
> > reasons.
> 
> Benefit of vendor specific API is code de-duplication and having common
> functions in one place. E.g. code for changing SMBIOS token does not
> have to be implemented in both userspace and kernel, just in kernel.
> 
> Also handling generic API requests from userspace in kernel and then
> pass them to firmware is a bit harder and less error prone. Also audit
> filters would be less easier...
> 
> I still think that we do not have to export WMI as is to userspace and
> personally I do not think it is the best solution even if Microsoft is
> doing it...
> 
> But if we are unable to design such API and vendor (e.g. Dell) already
> wants WMI API in userspace, then we probably should export it from them.
> 
> > All that said, I appreciate the concerns you've raised and they mirror many of
> > my own. I don't think we can just say "no, Windows Management Instrumentation
> is
> > only accessible in Linux within the kernel" as that is ultimately contrary to
> > the purpose of the mechanism. With those concerns in mind, I proposed the
> > general approach below which affords considerable freedom for vendors to
> manage
> > their systems while retaining the right to deny access to the existing Linux
> > kernel drivers. At the same time, it provides a general purpose interface to
> > userspace which won't collect legacy code we have to maintain forever.
> 
> The main concern is that WMI is something like meta-API or RPC. In most
> cases it would be needed to write "wrapper" code around to do call
> needed functions or do something. It is needed to written in kernel
> (e.g. for class drivers or for filters), but also vendor needs to
> duplicate functionality in userspace. And this does not seems to be
> ideal, probably it can be design-antipattern.
> 
> As wrote above, I'm fine with explicit whitelist of WMI GUIDs which will
> be exported to userspace after communication with vendor.
> 

What about GUID's not yet used by kernel drivers?  Would those default to
whitelist default to blacklist?  My preference would be to default to whitelist.
This allows new GUID's to be added later without needing to modify kernel
for something that kernel won't need to do anything immediately.

> One more thing: We should not provide new interface API/ABI between
> kernel and userspace without some open source implementation of
> userspace. This is IIRC some Linus's rule. And I'm not sure if vendors
> are going to provide some userspace WMI implementations as open
> source...
> 

At least for DELL SMBIOS calling interface GUID/method I plan to push
libsmbios and applications using it would then switch to new WMI interface.

[toc] | [prev] | [next] | [standalone]

#1626545

[Multipart message — attachments visible in raw view] — view raw

On Wednesday 19 April 2017 18:29:53 Mario.Limonciello@dell.com wrote:
> > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > will be exported to userspace after communication with vendor.
> 
> What about GUID's not yet used by kernel drivers?  Would those
> default to whitelist default to blacklist?  My preference would be
> to default to whitelist. This allows new GUID's to be added later
> without needing to modify kernel for something that kernel won't
> need to do anything immediately.

I understood it as there would be explicit whitelist in kernel and new 
GUIDs would be needed to add into whitelist, even those which do not 
have kernel wmi driver.

Exporting all GUIDs (to userspace) which are not bind to kernel driver 
has one big problem. If kernel introduce new wmi driver for such GUID 
then it block userspace to access it or at least would need to provide 
audit filter and something would be probably filtered. It means that 
some userspace applications which would use that GUIDs stops working 
after upgrading to new kernel. And we can be in situation where *user* 
need to decide: either use 3rd party userspace application from vendor 
which provide some special settings for your laptop, or use kernel 
module which provides standard rfkill/led/input class driver.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1626631

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Wednesday, April 19, 2017 11:55 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; rjw@rjwysocki.net; luto@amacapital.net;
> len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org;
> andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Wednesday 19 April 2017 18:29:53 Mario.Limonciello@dell.com wrote:
> > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > will be exported to userspace after communication with vendor.
> >
> > What about GUID's not yet used by kernel drivers?  Would those
> > default to whitelist default to blacklist?  My preference would be
> > to default to whitelist. This allows new GUID's to be added later
> > without needing to modify kernel for something that kernel won't
> > need to do anything immediately.
> 
> I understood it as there would be explicit whitelist in kernel and new
> GUIDs would be needed to add into whitelist, even those which do not
> have kernel wmi driver.
> 
> Exporting all GUIDs (to userspace) which are not bind to kernel driver
> has one big problem. If kernel introduce new wmi driver for such GUID
> then it block userspace to access it or at least would need to provide
> audit filter and something would be probably filtered. It means that
> some userspace applications which would use that GUIDs stops working
> after upgrading to new kernel. And we can be in situation where *user*
> need to decide: either use 3rd party userspace application from vendor
> which provide some special settings for your laptop, or use kernel
> module which provides standard rfkill/led/input class driver.
> 

If this proposal goes forward it would sound like to me an audit filter
would become a prerequisite for any new WMI kernel driver.  This is not
a problem to me.

This audience recommends the way for users to configure the system but 
of course cannot stop users from doing what they decide to do.  
We're all in agreement that the kernel should keep responsibility for some
of these functionalities.
If a new kernel WMI driver duplicates functionality that happens to find its 
way in userspace and the kernel audits that out yes the userspace 
application may start to  have less functionality, but better support 
would live in the kernel and the user would be better supported by 
the stack (for example could use standard rfkill userspace utilities).

[toc] | [prev] | [next] | [standalone]

#1627429

On Wednesday 19 April 2017 17:24:00 Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Wednesday, April 19, 2017 11:55 AM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: dvhart@infradead.org; rjw@rjwysocki.net; luto@amacapital.net;
> > len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org;
> > andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> > Subject: Re: RFC: WMI Enhancements
> > 
> > On Wednesday 19 April 2017 18:29:53 Mario.Limonciello@dell.com wrote:
> > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > > will be exported to userspace after communication with vendor.
> > >
> > > What about GUID's not yet used by kernel drivers?  Would those
> > > default to whitelist default to blacklist?  My preference would be
> > > to default to whitelist. This allows new GUID's to be added later
> > > without needing to modify kernel for something that kernel won't
> > > need to do anything immediately.
> > 
> > I understood it as there would be explicit whitelist in kernel and new
> > GUIDs would be needed to add into whitelist, even those which do not
> > have kernel wmi driver.
> > 
> > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > has one big problem. If kernel introduce new wmi driver for such GUID
> > then it block userspace to access it or at least would need to provide
> > audit filter and something would be probably filtered. It means that
> > some userspace applications which would use that GUIDs stops working
> > after upgrading to new kernel. And we can be in situation where *user*
> > need to decide: either use 3rd party userspace application from vendor
> > which provide some special settings for your laptop, or use kernel
> > module which provides standard rfkill/led/input class driver.
> > 
> 
> If this proposal goes forward it would sound like to me an audit filter
> would become a prerequisite for any new WMI kernel driver.  This is not
> a problem to me.

Not for any wmi driver, only for those which would like to export wmi
device to userspace.

> This audience recommends the way for users to configure the system but 
> of course cannot stop users from doing what they decide to do.  

Of course, but in above hypothetical example, user is in situation where
is unable to use both 3rd vendor application and together kernel
rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
manual module loading) what want to use.

But ideal solution is that both 3rd vendor application for firmware
settings and also rfkill kernel driver would work together without need
to rmmod/modprobe modules and without restarting 3rd vendor application.

> We're all in agreement that the kernel should keep responsibility for some
> of these functionalities.
> If a new kernel WMI driver duplicates functionality that happens to find its 
> way in userspace and the kernel audits that out yes the userspace 
> application may start to  have less functionality, but better support 
> would live in the kernel and the user would be better supported by 
> the stack (for example could use standard rfkill userspace utilities).

Ok. So it is acceptable solution/API/ABI for you & other Dell people?
Or is something more or different needed?

Darren, I hope that I understood your proposal with explicit whitelist
correctly. And is there already another vendor which want to use wmi
userspace on linux?

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1627805

On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
> On Wednesday 19 April 2017 17:24:00 Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: dvhart@infradead.org; rjw@rjwysocki.net; luto@amacapital.net;
> > > len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org;
> > > andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> > > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> > > Subject: Re: RFC: WMI Enhancements
> > > 
> > > On Wednesday 19 April 2017 18:29:53 Mario.Limonciello@dell.com wrote:
> > > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > > > will be exported to userspace after communication with vendor.
> > > >
> > > > What about GUID's not yet used by kernel drivers?  Would those
> > > > default to whitelist default to blacklist?  My preference would be
> > > > to default to whitelist. This allows new GUID's to be added later
> > > > without needing to modify kernel for something that kernel won't
> > > > need to do anything immediately.
> > > 
> > > I understood it as there would be explicit whitelist in kernel and new
> > > GUIDs would be needed to add into whitelist, even those which do not
> > > have kernel wmi driver.
> > > 
> > > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > > has one big problem. If kernel introduce new wmi driver for such GUID
> > > then it block userspace to access it or at least would need to provide
> > > audit filter and something would be probably filtered. It means that
> > > some userspace applications which would use that GUIDs stops working
> > > after upgrading to new kernel. And we can be in situation where *user*
> > > need to decide: either use 3rd party userspace application from vendor
> > > which provide some special settings for your laptop, or use kernel
> > > module which provides standard rfkill/led/input class driver.
> > > 
> > 
> > If this proposal goes forward it would sound like to me an audit filter
> > would become a prerequisite for any new WMI kernel driver.  This is not
> > a problem to me.
> 
> Not for any wmi driver, only for those which would like to export wmi
> device to userspace.

Correct.

> 
> > This audience recommends the way for users to configure the system but 
> > of course cannot stop users from doing what they decide to do.  
> 
> Of course, but in above hypothetical example, user is in situation where
> is unable to use both 3rd vendor application and together kernel
> rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
> manual module loading) what want to use.
> 
> But ideal solution is that both 3rd vendor application for firmware
> settings and also rfkill kernel driver would work together without need
> to rmmod/modprobe modules and without restarting 3rd vendor application.
> 
> > We're all in agreement that the kernel should keep responsibility for some
> > of these functionalities.
> > If a new kernel WMI driver duplicates functionality that happens to find its 
> > way in userspace and the kernel audits that out yes the userspace 
> > application may start to  have less functionality, but better support 
> > would live in the kernel and the user would be better supported by 
> > the stack (for example could use standard rfkill userspace utilities).
> 

Pali has raised a very good point which I want to get some feedback from Linus,
and perhaps tglx, hpa, and gregkh on. While Mario is expressing a very pragmatic
approach which I certainly appreciate, we have a very strong position that we do
not break userspace.

There have been exceptions for specific pseudo filesystems and such, but they
are rare. We would need to document the WMI commitment from the kernel to
userspace (e.g. any call may be filtered based on current Linux kernel WMI
usage, which may change over time). This sounds troublesome... will give this
some more thought.

> Ok. So it is acceptable solution/API/ABI for you & other Dell people?
> Or is something more or different needed?
> 
> Darren, I hope that I understood your proposal with explicit whitelist
> correctly. And is there already another vendor which want to use wmi
> userspace on linux?

It might be moot with Christoph's dynamic ID comment which I need to go review
in detail. Putting that aside for a moment, what I intended was for the platform
driver to whitelist GUIDs. But, that doesn't necessarily mean it has an explicit
list. The platform driver could have a blacklist and then walk through all
available GUIDs and export everything except those on the blacklist.

Now with Christoph's idea, we may be able to maintain a blacklist of GUIDs and a
whitelist of platforms which CAN export WMI, but not export any until userspace
requests a specific GUID be exported at which point it is checked against the
blacklist and then exported accordingly, at which point the WMI method filters
handle the rest.

> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com
> 

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1627497

With Andy's conversion of WMI to the driver model the GUIDs should
be our device ids.  Which means WMI can support the dynamic device
ID model, where you can echo a id to sysfs to bind an id - that way
people could add the GUIDs on demand to the pass through driver if
they need them even with the whitelist approach.

[toc] | [prev] | [next] | [standalone]

#1625658

On Tue, Apr 18, 2017 at 6:33 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
>> On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
>> > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
>> > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart <dvhart@infradead.org> wrote:
>> > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
>> > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart 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?
>> > > >> >
>> > > >> > 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.
>> > > >>
>> > > >> A couple of loose thoughts here.
>> > > >>
>> > > >> In principle there could be a "generic default WMI driver" or similar that would
>> > > >> "claim" all WMI "devices" that have not been "claimed" by anyone else and would
>> > > >> simply expose them to user space somehow (e.g. using a chardev interface).
>> > > >>
>> > > >> Then, depending on how that thing is implemented, opt-in etc should be possible
>> > > >> too.
>> > > >>
>> > > >
>> > > > I think we agree this would be an ideal approach.
>> > > >
>> > > > As we look into this more, it is becoming clear that the necessary functionality
>> > > > is not nicely divided into GUIDs for what is necessary in userspace and what is
>> > > > handled in the kernel. A single WMI METHOD GUID may be needed by userspace for
>> > > > certain functionality, while the kernel drivers may use it for something else.
>> > > >
>> > > > :-(
>> > > >
>> > > > The input to a WMI method is just a buffer, so it is very free form. One
>> > > > approach Mario has mentioned was to audit the user space WMI METHOD calls in the
>> > > > kernel platform drivers and reject those calls with arguments matching those
>> > > > issued by the kernel driver. This is likely to be complex and error prone in my
>> > > > opinion. However, I have not yet thought of another means to meet the
>> > > > requirement of having disjoint feature sets for userspace and kernel space via a
>> > > > mechanism that was effectively designed to be used solely from user space with
>> > > > vendor defined method signatures.
>> > > >
>> > > > Next step is to look at just how complex it would be to audit the method calls
>> > > > the kernel currently uses.
>> > >
>> > > I'm wondering whether it's really worth it.  We already allow doing
>> > > darned near anything using dcdbas.  Maybe the world won't end if we
>> > > expose a complete-ish ioctl interface to WMI.
>>
>> I guess the world wouldn't end then (it has not ended for far more serious
>> reasons so far after all), but this also doesn't feel entirely right.
>>
>> For one, if something is used inside of the kernel (by drivers etc), then
>> allowing user space to use the same thing directly is a recipe for unsupportable
>> mess IMO.
>
> I don't disagree. Unforuntately, the mechanism wasn't designed for this kind of
> mixed usage from what I can determine, so it doesn't lend itself to separation.
> We could kick out all the WMI drivers and encourage vendor/platform specific
> system daemons which read WMI and injected events and configured LEDs through
> sysfs, thus eliminating the user/kernel conflict - but it would only leave us
> with the problem of multiple userspace daemons competing for the same WMI
> METHODs -- and yeah, nobody's going for that :-D

Yeah, surely no one. :-)

>>
>> > > Also, dcdbas is, to put it mildly, a bit ridiculous.  It seems to be a
>> > > seriously awkward sysfs interface that allows you to, drumroll please,
>> > > issue outb and inb instructions.  It doesn't even check that it's
>> > > running on a Dell system.  It might be nice to deprecate it some day
>> > > in favor of a real interface.  I'd consider a low-level WMI ioctl
>> > > interface to be a vast improvement.
>> > >
>> >
>> > I've been reluctantly arriving here as well. Given that every WMI interface will
>> > be vendor specific, and non-discoverable, it seems unlikely developers will
>> > eagerly duplicate kernel functionality in user-space. And if they do, it will
>> > affect very few platforms.
>> >
>> > I still think it makes sense to only expose a WMI interface by default on some
>> > matching criteria. It could be DMI related, but I'd like to know if the UID is
>> > possible as well (it depends on how vendors use the UID, if consistently, not at
>> > all, etc.) Otherwise, the interface would not be enabled unless the user
>> > explicitly requests it via a module parameter or similar.
>>
>> To me, that should be the bare minimum, but I really think that mutual exclusion
>> between user space and the kernel needs to be ensured somehow when the
>> interface is enabled too.
>>
>> This looks similar to exposing _DSM functionality for certain device to user
>> space where some functions of the _DSM in question are already in use by
>> kernel code.  In that case I would think about an interface with a function
>> granularity (so it would check the GUID and the function and possibly the
>> ordering with respect to the other functions too before invoking the _DSM
>> on behalf of user space).
>
> This is also what I would consider to be ideal, but the mechanism doesn't lend
> itself to that level of granularity. WMI methods are not guaranteed to be broken
> up into sufficiently granular functionality that we can filter based on method
> ID. We would most likely end up in the position of having to audit the input
> buffer of every WMI call.
>
> For example, we can filter things the ASUS WMI Keyboard Filter method, but
> others are less specific, like Device Set, Bios Status, Device Status, Device
> Policy, etc.
>
> What we could do is make that the vendor's problem instead of the kernel's
> problem. Consider:
>
> * wmi.c adds method evaluation wrappers
> * add a wmi evaluation mutex
> * update *wmi.c drivers to use the new wrappers
> * platform drivers (dell-wmi.c, asus-wmi.c, etc.) must explicitly request
>   wmi.c to export the wmi chardev
> * platform drivers must explicitly whitelist each method ID to be exported
>   - they can automate this in a loop evaluating the wmi block if they wish
> * platform drivers *may* register a wmi evaluation filter which allows them
>   to audit the method id and input buffer to ensure it doesn't conflict with
>   in-kernel usage (their usage).
>
> I believe this is a reasonable compromise, and it places the burden on the
> platform drivers, and therefor on the vendors (in the best case) or the
> individual platform driver maintainers for less cooperative vendors. This
> contains any resulting exposure to the platforms which explicitly request it.

That would work for me.

Thanks,
Rafael

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web