linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RFC: WMI Enhancements
@ 2017-04-12 23:08 Darren Hart
  2017-04-13  7:32 ` Michał Kępień
                   ` (2 more replies)
  0 siblings, 3 replies; 76+ messages in thread
From: Darren Hart @ 2017-04-12 23:08 UTC (permalink / raw)
  To: Rafael Wysocki, Len Brown, Pali Rohár, Corentin Chary,
	Mario Limonciello, Andy Lutomirski, Andy Shevchenko
  Cc: LKML, platform-driver-x86, linux-pm

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.

b) The mechanism to expose WMI devices to userspace must allow for atomic
operation, which would exclude a sysfs interface involving multiple files.
Something like an ioctl or a char dev would be more appropriate.

Does anyone think differently regarding a) or b) ?

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. With or without MOF support however, I
think it makes sense to provide a common WMI mechanism to expose specific
devices/methods to userspace.

Appreciate your thoughts,

References:
1. https://msdn.microsoft.com/en-us/library/windows/hardware/Dn614028(v=vs.85).aspx
2. https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=platform/wmi
3. https://www.mail-archive.com/linux-acpi@vger.kernel.org/msg11686.html

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-12 23:08 RFC: WMI Enhancements Darren Hart
@ 2017-04-13  7:32 ` Michał Kępień
  2017-04-13 13:29   ` Mario.Limonciello
  2017-04-13 15:32   ` Andy Lutomirski
  2017-04-13  7:33 ` Pali Rohár
  2017-04-14 22:45 ` Rafael J. Wysocki
  2 siblings, 2 replies; 76+ messages in thread
From: Michał Kępień @ 2017-04-13  7:32 UTC (permalink / raw)
  To: Darren Hart
  Cc: Rafael Wysocki, Len Brown, Pali Rohár, Corentin Chary,
	Mario Limonciello, Andy Lutomirski, Andy Shevchenko, LKML,
	platform-driver-x86, linux-pm

> 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.

> 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.
> 
> b) The mechanism to expose WMI devices to userspace must allow for atomic
> operation, which would exclude a sysfs interface involving multiple files.
> Something like an ioctl or a char dev would be more appropriate.
> 
> Does anyone think differently regarding a) or b) ?

Please pardon my ignorance, but what do we actually gain by exposing WMI
to userspace?  Enabling applications to fetch SMBIOS data?  We already
have an interface for that.  Enabling applications to receive input
events?  Likewise.  You mentioned WMI's efficiency compared to SMI/SMM,
but is it a difference significant enough for anyone to notice?

I am biased here as I have had my own struggles with WMI in the past,
but it looks like a layer of indirection which brings little value, yet
is tricky to expose properly.  If there is a real-life use case that
makes this idea worthwhile, I would love to be enlightened.  

> 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).

[1] https://www.spinics.net/lists/platform-driver-x86/msg08201.html

-- 
Best regards,
Michał Kępień

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-12 23:08 RFC: WMI Enhancements Darren Hart
  2017-04-13  7:32 ` Michał Kępień
@ 2017-04-13  7:33 ` Pali Rohár
  2017-04-13 16:56   ` Darren Hart
  2017-04-14 22:45 ` Rafael J. Wysocki
  2 siblings, 1 reply; 76+ messages in thread
From: Pali Rohár @ 2017-04-13  7:33 UTC (permalink / raw)
  To: Darren Hart
  Cc: Rafael Wysocki, Len Brown, Corentin Chary, Mario Limonciello,
	Andy Lutomirski, Andy Shevchenko, LKML, platform-driver-x86,
	linux-pm

On Wednesday 12 April 2017 16:08:54 Darren Hart wrote:
> 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.

Maybe we should first ask, why linux userspace applications need direct
access to WMI? If we look at current WMI linux drivers, basically every
one translate WMI interface to some standard linux class driver (with
some extensions). This is something which should stay in kernel. E.g.
rfkill, backlight, led, input keyboard, ...

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-13  7:32 ` Michał Kępień
@ 2017-04-13 13:29   ` Mario.Limonciello
  2017-04-13 13:51     ` Pali Rohár
  2017-04-13 15:32   ` Andy Lutomirski
  1 sibling, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-13 13:29 UTC (permalink / raw)
  To: kernel, dvhart
  Cc: rjw, len.brown, pali.rohar, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Michał Kępień [mailto:kernel@kempniu.pl]
> Sent: Thursday, April 13, 2017 2:32 AM
> To: Darren Hart <dvhart@infradead.org>
> Cc: Rafael Wysocki <rjw@rjwysocki.net>; Len Brown <len.brown@intel.com>;
> Pali Rohár <pali.rohar@gmail.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
> 
> > 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.
> 
> > 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.
> >
> > b) The mechanism to expose WMI devices to userspace must allow for
> > atomic operation, which would exclude a sysfs interface involving multiple
> files.
> > Something like an ioctl or a char dev would be more appropriate.
> >
> > Does anyone think differently regarding a) or b) ?
> 
> Please pardon my ignorance, but what do we actually gain by exposing WMI to
> userspace?  Enabling applications to fetch SMBIOS data?  We already have an
> interface for that.  Enabling applications to receive input events?  Likewise.

Input notifications are just one aspect that received over WMI.  I don't see any
reason to move the notifications out of the kernel.

In terms of userspace applications, once a WMI interface to userspace is available
libsmbios would change over to that.  Applications using libsmbios would benefit.

> You mentioned WMI's efficiency compared to SMI/SMM, but is it a difference
> significant enough for anyone to notice?

At least for Dell there are optimizations being made when data is requested over 
the WMI-ACPI wrapper instead of directly via SMI/SMM.

For example if the data is a "static" table or the request is to something that is
passed thru to the EC it's a big waste of effort to put the CPU in SMM.

The savings there is significant.

> 
> I am biased here as I have had my own struggles with WMI in the past, but it
> looks like a layer of indirection which brings little value, yet is tricky to expose
> properly.  If there is a real-life use case that makes this idea worthwhile, I
> would love to be enlightened.
> 
> > 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).
> 
> [1] https://www.spinics.net/lists/platform-driver-x86/msg08201.html
> 
> --
> Best regards,
> Michał Kępień

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 13:29   ` Mario.Limonciello
@ 2017-04-13 13:51     ` Pali Rohár
  2017-04-13 15:34       ` Andy Lutomirski
  2017-04-13 15:40       ` Mario.Limonciello
  0 siblings, 2 replies; 76+ messages in thread
From: Pali Rohár @ 2017-04-13 13:51 UTC (permalink / raw)
  To: Mario.Limonciello, Hans de Goede
  Cc: kernel, dvhart, rjw, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Thursday 13 April 2017 13:29:41 Mario.Limonciello@dell.com wrote:
> > Please pardon my ignorance, but what do we actually gain by exposing WMI to
> > userspace?  Enabling applications to fetch SMBIOS data?  We already have an
> > interface for that.  Enabling applications to receive input events?  Likewise.
> 
> Input notifications are just one aspect that received over WMI.  I don't see any
> reason to move the notifications out of the kernel.
> 
> In terms of userspace applications, once a WMI interface to userspace is available
> libsmbios would change over to that.  Applications using libsmbios would benefit.

Really libsmbios matters here? Hans (added to thread) wrote that
libsmbios is a relic, something of ages long gone by and a normal user
should never use it.

If this is truth and libsmbios should not be used, then we probably do
not need to care about it in changes for WMI.

Hans, Mario, any comment/clarification about it?

> > You mentioned WMI's efficiency compared to SMI/SMM, but is it a difference
> > significant enough for anyone to notice?
> 
> At least for Dell there are optimizations being made when data is requested over 
> the WMI-ACPI wrapper instead of directly via SMI/SMM.
> 
> For example if the data is a "static" table or the request is to something that is
> passed thru to the EC it's a big waste of effort to put the CPU in SMM.
> 
> The savings there is significant.

Maybe we can use this Dell WMI-ACPI wrapper for kernel drivers instead
of current SMI/SMM direct access?

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13  7:32 ` Michał Kępień
  2017-04-13 13:29   ` Mario.Limonciello
@ 2017-04-13 15:32   ` Andy Lutomirski
  2017-04-13 15:39     ` Pali Rohár
                       ` (2 more replies)
  1 sibling, 3 replies; 76+ messages in thread
From: Andy Lutomirski @ 2017-04-13 15:32 UTC (permalink / raw)
  To: Michał Kępień
  Cc: Darren Hart, Rafael Wysocki, Len Brown, Pali Rohár,
	Corentin Chary, Mario Limonciello, Andy Lutomirski,
	Andy Shevchenko, LKML, platform-driver-x86, linux-pm

On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.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.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 13:51     ` Pali Rohár
@ 2017-04-13 15:34       ` Andy Lutomirski
  2017-04-13 15:40         ` Mario.Limonciello
  2017-04-13 15:40       ` Mario.Limonciello
  1 sibling, 1 reply; 76+ messages in thread
From: Andy Lutomirski @ 2017-04-13 15:34 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Mario.Limonciello, Hans de Goede, Michał Kępień,
	Darren Hart, Rafael J. Wysocki, Len Brown, corentin.chary,
	Andrew Lutomirski, Andy Shevchenko, linux-kernel,
	platform-driver-x86, linux-pm

On Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 13 April 2017 13:29:41 Mario.Limonciello@dell.com wrote:
>> > Please pardon my ignorance, but what do we actually gain by exposing WMI to
>> > userspace?  Enabling applications to fetch SMBIOS data?  We already have an
>> > interface for that.  Enabling applications to receive input events?  Likewise.
>>
>> Input notifications are just one aspect that received over WMI.  I don't see any
>> reason to move the notifications out of the kernel.
>>
>> In terms of userspace applications, once a WMI interface to userspace is available
>> libsmbios would change over to that.  Applications using libsmbios would benefit.
>
> Really libsmbios matters here? Hans (added to thread) wrote that
> libsmbios is a relic, something of ages long gone by and a normal user
> should never use it.
>
> If this is truth and libsmbios should not be used, then we probably do
> not need to care about it in changes for WMI.
>
> Hans, Mario, any comment/clarification about it?
>
>> > You mentioned WMI's efficiency compared to SMI/SMM, but is it a difference
>> > significant enough for anyone to notice?
>>
>> At least for Dell there are optimizations being made when data is requested over
>> the WMI-ACPI wrapper instead of directly via SMI/SMM.
>>
>> For example if the data is a "static" table or the request is to something that is
>> passed thru to the EC it's a big waste of effort to put the CPU in SMM.
>>
>> The savings there is significant.
>
> Maybe we can use this Dell WMI-ACPI wrapper for kernel drivers instead
> of current SMI/SMM direct access?
>

This would make sense to me.  IIRC the only functional difference is
the way that pointers are handled.  It shouldn't be that hard to make
it work for both variants, though.  It could look like:

buf = dell_smbios_alloc(...);
dell_smbios_put_pointer(buf, offset of pointer, offset of pointee);
dell_smbios_call(buf);

or similar.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 15:32   ` Andy Lutomirski
@ 2017-04-13 15:39     ` Pali Rohár
  2017-04-13 15:44       ` Andy Lutomirski
  2017-04-13 15:55     ` Mario.Limonciello
  2017-04-13 16:08     ` Darren Hart
  2 siblings, 1 reply; 76+ messages in thread
From: Pali Rohár @ 2017-04-13 15:39 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Michał Kępień,
	Darren Hart, Rafael Wysocki, Len Brown, Corentin Chary,
	Mario Limonciello, Andy Shevchenko, LKML, platform-driver-x86,
	linux-pm

[-- Attachment #1: Type: Text/Plain, Size: 989 bytes --]

On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl>
> wrote:
> > 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.

In this case, when WMI stay in kernel, MOF data could be exported via 
debugfs? I think there is no need to have them in sysfs stable ABI. As 
above usage (get WMI working on new platforms) looks like for debugging 
purpose.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-13 15:34       ` Andy Lutomirski
@ 2017-04-13 15:40         ` Mario.Limonciello
  2017-04-13 16:06           ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-13 15:40 UTC (permalink / raw)
  To: luto, pali.rohar
  Cc: hdegoede, kernel, dvhart, rjw, len.brown, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Thursday, April 13, 2017 10:35 AM
> To: Pali Rohár <pali.rohar@gmail.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Hans de Goede
> <hdegoede@redhat.com>; Michał Kępień <kernel@kempniu.pl>; Darren Hart
> <dvhart@infradead.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown
> <len.brown@intel.com>; corentin.chary@gmail.com; Andrew Lutomirski
> <luto@kernel.org>; Andy Shevchenko <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 Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Thursday 13 April 2017 13:29:41 Mario.Limonciello@dell.com wrote:
> >> > Please pardon my ignorance, but what do we actually gain by
> >> > exposing WMI to userspace?  Enabling applications to fetch SMBIOS
> >> > data?  We already have an interface for that.  Enabling applications to
> receive input events?  Likewise.
> >>
> >> Input notifications are just one aspect that received over WMI.  I
> >> don't see any reason to move the notifications out of the kernel.
> >>
> >> In terms of userspace applications, once a WMI interface to userspace
> >> is available libsmbios would change over to that.  Applications using
> libsmbios would benefit.
> >
> > Really libsmbios matters here? Hans (added to thread) wrote that
> > libsmbios is a relic, something of ages long gone by and a normal user
> > should never use it.
> >
> > If this is truth and libsmbios should not be used, then we probably do
> > not need to care about it in changes for WMI.
> >
> > Hans, Mario, any comment/clarification about it?
> >
> >> > You mentioned WMI's efficiency compared to SMI/SMM, but is it a
> >> > difference significant enough for anyone to notice?
> >>
> >> At least for Dell there are optimizations being made when data is
> >> requested over the WMI-ACPI wrapper instead of directly via SMI/SMM.
> >>
> >> For example if the data is a "static" table or the request is to
> >> something that is passed thru to the EC it's a big waste of effort to put the
> CPU in SMM.
> >>
> >> The savings there is significant.
> >
> > Maybe we can use this Dell WMI-ACPI wrapper for kernel drivers instead
> > of current SMI/SMM direct access?
> >
> 
> This would make sense to me.  IIRC the only functional difference is the way
> that pointers are handled.  It shouldn't be that hard to make it work for both
> variants, though.  It could look like:
> 
> buf = dell_smbios_alloc(...);
> dell_smbios_put_pointer(buf, offset of pointer, offset of pointee);
> dell_smbios_call(buf);
> 
> or similar.

Yes, I was going to encourage that kernel change after this WMI discussion 
had some conclusions.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-13 13:51     ` Pali Rohár
  2017-04-13 15:34       ` Andy Lutomirski
@ 2017-04-13 15:40       ` Mario.Limonciello
  2017-04-18  7:36         ` Andy Shevchenko
  1 sibling, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-13 15:40 UTC (permalink / raw)
  To: pali.rohar, hdegoede
  Cc: kernel, dvhart, rjw, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm



> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Thursday, April 13, 2017 8:51 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>; Hans de Goede
> <hdegoede@redhat.com>
> Cc: kernel@kempniu.pl; dvhart@infradead.org; rjw@rjwysocki.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 Thursday 13 April 2017 13:29:41 Mario.Limonciello@dell.com wrote:
> > > Please pardon my ignorance, but what do we actually gain by exposing
> > > WMI to userspace?  Enabling applications to fetch SMBIOS data?  We
> > > already have an interface for that.  Enabling applications to receive input
> events?  Likewise.
> >
> > Input notifications are just one aspect that received over WMI.  I
> > don't see any reason to move the notifications out of the kernel.
> >
> > In terms of userspace applications, once a WMI interface to userspace
> > is available libsmbios would change over to that.  Applications using
> libsmbios would benefit.
> 
> Really libsmbios matters here? Hans (added to thread) wrote that libsmbios is
> a relic, something of ages long gone by and a normal user should never use it.
> 	

A normal user shouldn't be using it directly, but libsmbios is used by a few open 
source tools as a dependency.  It's also used in many Dell manageability tools.

> If this is truth and libsmbios should not be used, then we probably do not need
> to care about it in changes for WMI.
> 
> Hans, Mario, any comment/clarification about it?
> 
> > > You mentioned WMI's efficiency compared to SMI/SMM, but is it a
> > > difference significant enough for anyone to notice?
> >
> > At least for Dell there are optimizations being made when data is
> > requested over the WMI-ACPI wrapper instead of directly via SMI/SMM.
> >
> > For example if the data is a "static" table or the request is to
> > something that is passed thru to the EC it's a big waste of effort to put the
> CPU in SMM.
> >
> > The savings there is significant.
> 
> Maybe we can use this Dell WMI-ACPI wrapper for kernel drivers instead of
> current SMI/SMM direct access?
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 15:39     ` Pali Rohár
@ 2017-04-13 15:44       ` Andy Lutomirski
  2017-04-13 16:09         ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Andy Lutomirski @ 2017-04-13 15:44 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Andy Lutomirski, Michał Kępień,
	Darren Hart, Rafael Wysocki, Len Brown, Corentin Chary,
	Mario Limonciello, Andy Shevchenko, LKML, platform-driver-x86,
	linux-pm

On Thu, Apr 13, 2017 at 8:39 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
>> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl>
>> wrote:
>> > 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.
>
> In this case, when WMI stay in kernel, MOF data could be exported via
> debugfs? I think there is no need to have them in sysfs stable ABI. As
> above usage (get WMI working on new platforms) looks like for debugging
> purpose.
>

That's a reasonable point.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-13 15:32   ` Andy Lutomirski
  2017-04-13 15:39     ` Pali Rohár
@ 2017-04-13 15:55     ` Mario.Limonciello
  2017-04-13 15:57       ` Andy Lutomirski
  2017-04-13 17:02       ` Darren Hart
  2017-04-13 16:08     ` Darren Hart
  2 siblings, 2 replies; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-13 15:55 UTC (permalink / raw)
  To: luto, kernel
  Cc: dvhart, rjw, len.brown, pali.rohar, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm



> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Thursday, April 13, 2017 10:33 AM
> To: Michał Kępień <kernel@kempniu.pl>
> Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>;
> Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.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 Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.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.

So there are plenty of other things that can be done by WMI that don't
really make sense to live in the kernel, particularly on what Dell exposes via
WMI.

If the desire of this group ends up being to not expose WMI by default,
I'd like to at least propose it be exposed for the GUID's Dell is using.

Perhaps as part of changing dell-smbios to use WMI, also extend it's
functionality to userspace.

> 
> >> 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.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 15:55     ` Mario.Limonciello
@ 2017-04-13 15:57       ` Andy Lutomirski
  2017-04-13 16:54         ` Mario.Limonciello
  2017-04-13 17:02       ` Darren Hart
  1 sibling, 1 reply; 76+ messages in thread
From: Andy Lutomirski @ 2017-04-13 15:57 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: Andrew Lutomirski, Michał Kępień,
	Darren Hart, Rafael J. Wysocki, Len Brown, Pali Rohár,
	Corentin Chary, Andy Shevchenko, linux-kernel,
	platform-driver-x86, linux-pm

On Thu, Apr 13, 2017 at 8:55 AM,  <Mario.Limonciello@dell.com> wrote:
>
>
>> -----Original Message-----
>> From: Andy Lutomirski [mailto:luto@kernel.org]
>> Sent: Thursday, April 13, 2017 10:33 AM
>> To: Michał Kępień <kernel@kempniu.pl>
>> Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>;
>> Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.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 Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.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.
>
> So there are plenty of other things that can be done by WMI that don't
> really make sense to live in the kernel, particularly on what Dell exposes via
> WMI.
>
> If the desire of this group ends up being to not expose WMI by default,
> I'd like to at least propose it be exposed for the GUID's Dell is using.

Is it just the "call SMBIOS" GUID or are there other things?

>
> Perhaps as part of changing dell-smbios to use WMI, also extend it's
> functionality to userspace.
>

Could this still result in userspace and the kernel fighting over
control of various bits of the system?  If so, that's a bit less than
ideal.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 15:40         ` Mario.Limonciello
@ 2017-04-13 16:06           ` Darren Hart
  0 siblings, 0 replies; 76+ messages in thread
From: Darren Hart @ 2017-04-13 16:06 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: luto, pali.rohar, hdegoede, kernel, rjw, len.brown,
	corentin.chary, andriy.shevchenko, linux-kernel,
	platform-driver-x86, linux-pm

On Thu, Apr 13, 2017 at 03:40:08PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Andy Lutomirski [mailto:luto@kernel.org]
> > Sent: Thursday, April 13, 2017 10:35 AM
> > To: Pali Rohár <pali.rohar@gmail.com>
> > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Hans de Goede
> > <hdegoede@redhat.com>; Michał Kępień <kernel@kempniu.pl>; Darren Hart
> > <dvhart@infradead.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown
> > <len.brown@intel.com>; corentin.chary@gmail.com; Andrew Lutomirski
> > <luto@kernel.org>; Andy Shevchenko <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 Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > On Thursday 13 April 2017 13:29:41 Mario.Limonciello@dell.com wrote:
> > >> > Please pardon my ignorance, but what do we actually gain by
> > >> > exposing WMI to userspace?  Enabling applications to fetch SMBIOS
> > >> > data?  We already have an interface for that.  Enabling applications to
> > receive input events?  Likewise.
> > >>
> > >> Input notifications are just one aspect that received over WMI.  I
> > >> don't see any reason to move the notifications out of the kernel.
> > >>
> > >> In terms of userspace applications, once a WMI interface to userspace
> > >> is available libsmbios would change over to that.  Applications using
> > libsmbios would benefit.
> > >
> > > Really libsmbios matters here? Hans (added to thread) wrote that
> > > libsmbios is a relic, something of ages long gone by and a normal user
> > > should never use it.
> > >
> > > If this is truth and libsmbios should not be used, then we probably do
> > > not need to care about it in changes for WMI.
> > >
> > > Hans, Mario, any comment/clarification about it?
> > >
> > >> > You mentioned WMI's efficiency compared to SMI/SMM, but is it a
> > >> > difference significant enough for anyone to notice?
> > >>
> > >> At least for Dell there are optimizations being made when data is
> > >> requested over the WMI-ACPI wrapper instead of directly via SMI/SMM.
> > >>
> > >> For example if the data is a "static" table or the request is to
> > >> something that is passed thru to the EC it's a big waste of effort to put the
> > CPU in SMM.
> > >>
> > >> The savings there is significant.
> > >
> > > Maybe we can use this Dell WMI-ACPI wrapper for kernel drivers instead
> > > of current SMI/SMM direct access?
> > >
> > 
> > This would make sense to me.  IIRC the only functional difference is the way
> > that pointers are handled.  It shouldn't be that hard to make it work for both
> > variants, though.  It could look like:
> > 
> > buf = dell_smbios_alloc(...);
> > dell_smbios_put_pointer(buf, offset of pointer, offset of pointee);
> > dell_smbios_call(buf);
> > 
> > or similar.
> 
> Yes, I was going to encourage that kernel change after this WMI discussion 
> had some conclusions.

Agreed on this point as well.

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 15:32   ` Andy Lutomirski
  2017-04-13 15:39     ` Pali Rohár
  2017-04-13 15:55     ` Mario.Limonciello
@ 2017-04-13 16:08     ` Darren Hart
  2 siblings, 0 replies; 76+ messages in thread
From: Darren Hart @ 2017-04-13 16:08 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Michał Kępień,
	Rafael Wysocki, Len Brown, Pali Rohár, Corentin Chary,
	Mario Limonciello, Andy Shevchenko, LKML, platform-driver-x86,
	linux-pm

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@kempniu.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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 15:44       ` Andy Lutomirski
@ 2017-04-13 16:09         ` Darren Hart
  0 siblings, 0 replies; 76+ messages in thread
From: Darren Hart @ 2017-04-13 16:09 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Pali Rohár, Michał Kępień,
	Rafael Wysocki, Len Brown, Corentin Chary, Mario Limonciello,
	Andy Shevchenko, LKML, platform-driver-x86, linux-pm

On Thu, Apr 13, 2017 at 08:44:28AM -0700, Andy Lutomirski wrote:
> On Thu, Apr 13, 2017 at 8:39 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
> >> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl>
> >> wrote:
> >> > 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.
> >
> > In this case, when WMI stay in kernel, MOF data could be exported via
> > debugfs? I think there is no need to have them in sysfs stable ABI. As
> > above usage (get WMI working on new platforms) looks like for debugging
> > purpose.
> >
> 
> That's a reasonable point.
> 

Also agreed.

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-13 15:57       ` Andy Lutomirski
@ 2017-04-13 16:54         ` Mario.Limonciello
  2017-04-13 17:06           ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-13 16:54 UTC (permalink / raw)
  To: luto
  Cc: kernel, dvhart, rjw, len.brown, pali.rohar, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Thursday, April 13, 2017 10:58 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: Andrew Lutomirski <luto@kernel.org>; Michał Kępień <kernel@kempniu.pl>;
> Darren Hart <dvhart@infradead.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len
> Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin
> Chary <corentin.chary@gmail.com>; Andy Shevchenko
> <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 Thu, Apr 13, 2017 at 8:55 AM,  <Mario.Limonciello@dell.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Andy Lutomirski [mailto:luto@kernel.org]
> >> Sent: Thursday, April 13, 2017 10:33 AM
> >> To: Michał Kępień <kernel@kempniu.pl>
> >> Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>;
> >> Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.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 Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.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.
> >
> > So there are plenty of other things that can be done by WMI that don't
> > really make sense to live in the kernel, particularly on what Dell exposes via
> > WMI.
> >
> > If the desire of this group ends up being to not expose WMI by default,
> > I'd like to at least propose it be exposed for the GUID's Dell is using.
> 
> Is it just the "call SMBIOS" GUID or are there other things?

There are some other things too, but I'll need to discuss with an internal
team first  to clarify.

> 
> >
> > Perhaps as part of changing dell-smbios to use WMI, also extend it's
> > functionality to userspace.
> >
> 
> Could this still result in userspace and the kernel fighting over
> control of various bits of the system?  If so, that's a bit less than
> ideal.

No more than exists today with the dcdbas SMI interface (which
only if you manually run userspace tools that manipulate the same
data you can do that technically).

We're all reasonable folks, if there is an instance of this that comes
up we can make changes to userspace to fix it.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13  7:33 ` Pali Rohár
@ 2017-04-13 16:56   ` Darren Hart
  2017-04-13 20:38     ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-04-13 16:56 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Rafael Wysocki, Len Brown, Corentin Chary, Mario Limonciello,
	Andy Lutomirski, Andy Shevchenko, LKML, platform-driver-x86,
	linux-pm

On Thu, Apr 13, 2017 at 09:33:39AM +0200, Pali Rohár wrote:
> On Wednesday 12 April 2017 16:08:54 Darren Hart wrote:
> > 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.
> 
> Maybe we should first ask, why linux userspace applications need direct
> access to WMI? If we look at current WMI linux drivers, basically every
> one translate WMI interface to some standard linux class driver (with
> some extensions). This is something which should stay in kernel. E.g.
> rfkill, backlight, led, input keyboard, ...

Agreed on these common functions. Whenever we have a common subsystem / class
driver, we should make use of that. This is another good reason not to publish
all WMI methods wholesale to userspace. That said, class drivers are written
after we eventually see a pattern in drivers and refactor them to encapsulate a
common functionality. This takes time, and is only worth doing for things that
are truly common.

WMI (Windows Management Instrumentation) is very generic and is intended to
provide vendors the ability to manage and configure the systems at the firmware
level.

I am a strong supporter of the following philosophy with respect to supporting
innovation:
"Enable them to enable themselves and get out of their way"

I've followed this approach over the years to encourage upstream first software
development, open-first policy toward specifications and documentation, proper
license selection, and development of new mechanisms in existing standards, like
ACPI _DSD. All of these serve to support innovation by removing bottlenecks and
enabling developers to be independent.

What I don't want to see is the Linux kernel becoming a bottleneck to feature
parity with Windows (or to becoming the lead vehicle for new features). When a
vendor has a feature they want to expose which they determine to be a value
proposition for their product, I don't want the lack of a class driver to get in
the way. Exposing specific GUIDs is a minimal and easy to upstream change which
would enable rapid feature enabling.

Perhaps I should have led with this :-)

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 15:55     ` Mario.Limonciello
  2017-04-13 15:57       ` Andy Lutomirski
@ 2017-04-13 17:02       ` Darren Hart
  2017-04-13 17:32         ` Andy Lutomirski
  1 sibling, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-04-13 17:02 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: luto, kernel, rjw, len.brown, pali.rohar, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Thu, Apr 13, 2017 at 03:55:01PM +0000, Mario.Limonciello@dell.com wrote:
> 
> 
> > -----Original Message-----
> > From: Andy Lutomirski [mailto:luto@kernel.org]
> > Sent: Thursday, April 13, 2017 10:33 AM
> > To: Michał Kępień <kernel@kempniu.pl>
> > Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>;
> > Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.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 Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.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.
> 
> So there are plenty of other things that can be done by WMI that don't
> really make sense to live in the kernel, particularly on what Dell exposes via
> WMI.
> 
> If the desire of this group ends up being to not expose WMI by default,
> I'd like to at least propose it be exposed for the GUID's Dell is using.
> 

What I'm thinking is an explicit list of GUIDs within the drivers which are to
be exposed to user space. The rationale being:

* GUIDs which are managed by kernel drivers (LEDs, hotkeys, etc.) should not be
  exposed to userspace.

* Management GUIDs should not change frequently

* Management GUIDs are a trivial add, equivalent to adding a DEVICE ID to an
  existing driver. This means minimal review time to get upstream, and the
  ability to include in stable backports as needed. I haven't confirmed
  this with Greg KH, but I think I can make the case, especially after
  Andy L's WMI-as-a-bus patches.

> Perhaps as part of changing dell-smbios to use WMI, also extend it's
> functionality to userspace.

That would be consistent with the above in my opinion.

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 16:54         ` Mario.Limonciello
@ 2017-04-13 17:06           ` Darren Hart
  2017-04-13 17:39             ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-04-13 17:06 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: luto, kernel, rjw, len.brown, pali.rohar, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Thu, Apr 13, 2017 at 04:54:25PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Andy Lutomirski [mailto:luto@kernel.org]
> > Sent: Thursday, April 13, 2017 10:58 AM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: Andrew Lutomirski <luto@kernel.org>; Michał Kępień <kernel@kempniu.pl>;
> > Darren Hart <dvhart@infradead.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len
> > Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin
> > Chary <corentin.chary@gmail.com>; Andy Shevchenko
> > <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 Thu, Apr 13, 2017 at 8:55 AM,  <Mario.Limonciello@dell.com> wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Andy Lutomirski [mailto:luto@kernel.org]
> > >> Sent: Thursday, April 13, 2017 10:33 AM
> > >> To: Michał Kępień <kernel@kempniu.pl>
> > >> Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>;
> > >> Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.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 Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.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.
> > >
> > > So there are plenty of other things that can be done by WMI that don't
> > > really make sense to live in the kernel, particularly on what Dell exposes via
> > > WMI.
> > >
> > > If the desire of this group ends up being to not expose WMI by default,
> > > I'd like to at least propose it be exposed for the GUID's Dell is using.
> > 
> > Is it just the "call SMBIOS" GUID or are there other things?
> 
> There are some other things too, but I'll need to discuss with an internal
> team first  to clarify.
> 
> > 
> > >
> > > Perhaps as part of changing dell-smbios to use WMI, also extend it's
> > > functionality to userspace.
> > >
> > 
> > Could this still result in userspace and the kernel fighting over
> > control of various bits of the system?  If so, that's a bit less than
> > ideal.
> 
> No more than exists today with the dcdbas SMI interface (which
> only if you manually run userspace tools that manipulate the same
> data you can do that technically).
> 
> We're all reasonable folks, if there is an instance of this that comes
> up we can make changes to userspace to fix it.

Right. As Pali pointed out previously, if there is an existing class driver /
subsystem which supports this functionality we should use that.

I suppose one risk will be one GUID exposing both types of methods. Those which
are used by kernel drivers, and those which have no kernel support. Or worse,
methods which have multiple behaviors depending on their input arguments.

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 17:02       ` Darren Hart
@ 2017-04-13 17:32         ` Andy Lutomirski
  2017-04-13 17:45           ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Andy Lutomirski @ 2017-04-13 17:32 UTC (permalink / raw)
  To: Darren Hart
  Cc: Mario.Limonciello, Andrew Lutomirski,
	Michał Kępień,
	Rafael J. Wysocki, Len Brown, Pali Rohár, Corentin Chary,
	Andy Shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Thu, Apr 13, 2017 at 10:02 AM, Darren Hart <dvhart@infradead.org> wrote:
> On Thu, Apr 13, 2017 at 03:55:01PM +0000, Mario.Limonciello@dell.com wrote:
>>
>>
>> > -----Original Message-----
>> > From: Andy Lutomirski [mailto:luto@kernel.org]
>> > Sent: Thursday, April 13, 2017 10:33 AM
>> > To: Michał Kępień <kernel@kempniu.pl>
>> > Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>;
>> > Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.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 Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.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.
>>
>> So there are plenty of other things that can be done by WMI that don't
>> really make sense to live in the kernel, particularly on what Dell exposes via
>> WMI.
>>
>> If the desire of this group ends up being to not expose WMI by default,
>> I'd like to at least propose it be exposed for the GUID's Dell is using.
>>
>
> What I'm thinking is an explicit list of GUIDs within the drivers which are to
> be exposed to user space. The rationale being:
>
> * GUIDs which are managed by kernel drivers (LEDs, hotkeys, etc.) should not be
>   exposed to userspace.
>
> * Management GUIDs should not change frequently
>
> * Management GUIDs are a trivial add, equivalent to adding a DEVICE ID to an
>   existing driver. This means minimal review time to get upstream, and the
>   ability to include in stable backports as needed. I haven't confirmed
>   this with Greg KH, but I think I can make the case, especially after
>   Andy L's WMI-as-a-bus patches.

Would this be a class driver that would expose a chardev for each
bound GUID?  I agree that this makes a lot more sense than trying to
shoehorn it into sysfs.  Especially since we'd want closing the
chardev to disable any "expensive" collections that have been enabled
by ioctl on that chardev.  Exposing Dell's smbios entry point through
this type of device seems reasonable to me.

If we go this route, then I think that exposing the MOF through sysfs
would make sense -- after all, someone might actually want to parse
the thing for production purposes.

On a sort-of-on-topic note, there's one platform feature that we
complete fail to handle in the kernel that might be nice to add before
it gets kludged into lots of userspace code: battery charge controls.
Thinkpads expose charge thresholds using abominable interfaces, but I
think they've all been reverse-engineered.  Dell probably has them,
and I bet that Mario would consider telling us how to use them if we
asked nicely.  It might be nice to expose these generically through
sysfs somewhere.

I'm guilty myself:

https://github.com/amluto/tp_charge

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-13 17:06           ` Darren Hart
@ 2017-04-13 17:39             ` Mario.Limonciello
  2017-04-13 17:44               ` Andy Lutomirski
  2017-04-18  7:54               ` Pali Rohár
  0 siblings, 2 replies; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-13 17:39 UTC (permalink / raw)
  To: dvhart
  Cc: luto, kernel, rjw, len.brown, pali.rohar, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Thursday, April 13, 2017 12:06 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: luto@kernel.org; kernel@kempniu.pl; rjw@rjwysocki.net;
> len.brown@intel.com; pali.rohar@gmail.com; corentin.chary@gmail.com;
> 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 Thu, Apr 13, 2017 at 04:54:25PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Andy Lutomirski [mailto:luto@kernel.org]
> > > Sent: Thursday, April 13, 2017 10:58 AM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: Andrew Lutomirski <luto@kernel.org>; Michał Kępień
> <kernel@kempniu.pl>;
> > > Darren Hart <dvhart@infradead.org>; Rafael J. Wysocki <rjw@rjwysocki.net>;
> Len
> > > Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin
> > > Chary <corentin.chary@gmail.com>; Andy Shevchenko
> > > <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 Thu, Apr 13, 2017 at 8:55 AM,  <Mario.Limonciello@dell.com> wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Andy Lutomirski [mailto:luto@kernel.org]
> > > >> Sent: Thursday, April 13, 2017 10:33 AM
> > > >> To: Michał Kępień <kernel@kempniu.pl>
> > > >> Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki
> <rjw@rjwysocki.net>;
> > > >> Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.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 Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.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.
> > > >
> > > > So there are plenty of other things that can be done by WMI that don't
> > > > really make sense to live in the kernel, particularly on what Dell exposes via
> > > > WMI.
> > > >
> > > > If the desire of this group ends up being to not expose WMI by default,
> > > > I'd like to at least propose it be exposed for the GUID's Dell is using.
> > >
> > > Is it just the "call SMBIOS" GUID or are there other things?
> >
> > There are some other things too, but I'll need to discuss with an internal
> > team first  to clarify.
> >
> > >
> > > >
> > > > Perhaps as part of changing dell-smbios to use WMI, also extend it's
> > > > functionality to userspace.
> > > >
> > >
> > > Could this still result in userspace and the kernel fighting over
> > > control of various bits of the system?  If so, that's a bit less than
> > > ideal.
> >
> > No more than exists today with the dcdbas SMI interface (which
> > only if you manually run userspace tools that manipulate the same
> > data you can do that technically).
> >
> > We're all reasonable folks, if there is an instance of this that comes
> > up we can make changes to userspace to fix it.
> 
> Right. As Pali pointed out previously, if there is an existing class driver /
> subsystem which supports this functionality we should use that.
> 
> I suppose one risk will be one GUID exposing both types of methods. Those which
> are used by kernel drivers, and those which have no kernel support. Or worse,
> methods which have multiple behaviors depending on their input arguments.
> 
> --

Well the "most" interesting to me is the SMBIOS calling interface on the
regular Dell GUID (WMBA IIRC).  That's what is used to manipulate keyboard
LED timeouts in dell-laptop (although through direct SMI today).

It's also what is used for other SMBIOS calls like changing random BIOS settings
that shouldn't be generically exposed in sysfs but should be controlled by
manageability tools.

Example: turning on/off legacy option ROM or changing legacy boot order.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 17:39             ` Mario.Limonciello
@ 2017-04-13 17:44               ` Andy Lutomirski
  2017-04-13 17:49                 ` Mario.Limonciello
  2017-04-18  7:54               ` Pali Rohár
  1 sibling, 1 reply; 76+ messages in thread
From: Andy Lutomirski @ 2017-04-13 17:44 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: Darren Hart, Andrew Lutomirski, Michał Kępień,
	Rafael J. Wysocki, Len Brown, Pali Rohár, Corentin Chary,
	Andy Shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Thu, Apr 13, 2017 at 10:39 AM,  <Mario.Limonciello@dell.com> wrote:
>> -----Original Message-----
>> From: Darren Hart [mailto:dvhart@infradead.org]
>> Sent: Thursday, April 13, 2017 12:06 PM
>> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
>> Cc: luto@kernel.org; kernel@kempniu.pl; rjw@rjwysocki.net;
>> len.brown@intel.com; pali.rohar@gmail.com; corentin.chary@gmail.com;
>> 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
>>

> Well the "most" interesting to me is the SMBIOS calling interface on the
> regular Dell GUID (WMBA IIRC).  That's what is used to manipulate keyboard
> LED timeouts in dell-laptop (although through direct SMI today).
>
> It's also what is used for other SMBIOS calls like changing random BIOS settings
> that shouldn't be generically exposed in sysfs but should be controlled by
> manageability tools.
>
> Example: turning on/off legacy option ROM or changing legacy boot order.
>

IIUC we basically can't expose the SMI--based interface to this entry
point to userspace because of its use of physical addressing.  It is
reasonably safe to expose the WMI version?  (IOW should be expect that
it doesn't enable kernel-mode or SMM code execution?)

TBH, I've occasionally considered writing a driver to expose SMM code
execution on systems with a known reliable exploit :)

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-13 17:32         ` Andy Lutomirski
@ 2017-04-13 17:45           ` Mario.Limonciello
  0 siblings, 0 replies; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-13 17:45 UTC (permalink / raw)
  To: luto, dvhart
  Cc: kernel, rjw, len.brown, pali.rohar, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Thursday, April 13, 2017 12:33 PM
> To: Darren Hart <dvhart@infradead.org>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Andrew Lutomirski
> <luto@kernel.org>; Michał Kępień <kernel@kempniu.pl>; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Len Brown <len.brown@intel.com>; Pali Rohár
> <pali.rohar@gmail.com>; Corentin Chary <corentin.chary@gmail.com>; Andy
> Shevchenko <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 Thu, Apr 13, 2017 at 10:02 AM, Darren Hart <dvhart@infradead.org> wrote:
> > On Thu, Apr 13, 2017 at 03:55:01PM +0000, Mario.Limonciello@dell.com wrote:
> >>
> >>
> >> > -----Original Message-----
> >> > From: Andy Lutomirski [mailto:luto@kernel.org]
> >> > Sent: Thursday, April 13, 2017 10:33 AM
> >> > To: Michał Kępień <kernel@kempniu.pl>
> >> > Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki
> <rjw@rjwysocki.net>;
> >> > Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.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 Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.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.
> >>
> >> So there are plenty of other things that can be done by WMI that don't
> >> really make sense to live in the kernel, particularly on what Dell exposes via
> >> WMI.
> >>
> >> If the desire of this group ends up being to not expose WMI by default,
> >> I'd like to at least propose it be exposed for the GUID's Dell is using.
> >>
> >
> > What I'm thinking is an explicit list of GUIDs within the drivers which are to
> > be exposed to user space. The rationale being:
> >
> > * GUIDs which are managed by kernel drivers (LEDs, hotkeys, etc.) should not be
> >   exposed to userspace.
> >
> > * Management GUIDs should not change frequently
> >
> > * Management GUIDs are a trivial add, equivalent to adding a DEVICE ID to an
> >   existing driver. This means minimal review time to get upstream, and the
> >   ability to include in stable backports as needed. I haven't confirmed
> >   this with Greg KH, but I think I can make the case, especially after
> >   Andy L's WMI-as-a-bus patches.
> 
> Would this be a class driver that would expose a chardev for each
> bound GUID?  I agree that this makes a lot more sense than trying to
> shoehorn it into sysfs.  Especially since we'd want closing the
> chardev to disable any "expensive" collections that have been enabled
> by ioctl on that chardev.  Exposing Dell's smbios entry point through
> this type of device seems reasonable to me.
> 
> If we go this route, then I think that exposing the MOF through sysfs
> would make sense -- after all, someone might actually want to parse
> the thing for production purposes.

I agree.

> 
> On a sort-of-on-topic note, there's one platform feature that we
> complete fail to handle in the kernel that might be nice to add before
> it gets kludged into lots of userspace code: battery charge controls.
> Thinkpads expose charge thresholds using abominable interfaces, but I
> think they've all been reverse-engineered.  Dell probably has them,
> and I bet that Mario would consider telling us how to use them if we
> asked nicely.  It might be nice to expose these generically through
> sysfs somewhere.
> 

Sure.  They're part of the token interface.
https://github.com/dell/libsmbios/blob/master/doc/token_list.csv#L834

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-13 17:44               ` Andy Lutomirski
@ 2017-04-13 17:49                 ` Mario.Limonciello
  0 siblings, 0 replies; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-13 17:49 UTC (permalink / raw)
  To: luto
  Cc: dvhart, kernel, rjw, len.brown, pali.rohar, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Thursday, April 13, 2017 12:44 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: Darren Hart <dvhart@infradead.org>; Andrew Lutomirski <luto@kernel.org>;
> Michał Kępień <kernel@kempniu.pl>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len
> Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin
> Chary <corentin.chary@gmail.com>; Andy Shevchenko
> <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 Thu, Apr 13, 2017 at 10:39 AM,  <Mario.Limonciello@dell.com> wrote:
> >> -----Original Message-----
> >> From: Darren Hart [mailto:dvhart@infradead.org]
> >> Sent: Thursday, April 13, 2017 12:06 PM
> >> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> >> Cc: luto@kernel.org; kernel@kempniu.pl; rjw@rjwysocki.net;
> >> len.brown@intel.com; pali.rohar@gmail.com; corentin.chary@gmail.com;
> >> 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
> >>
> 
> > Well the "most" interesting to me is the SMBIOS calling interface on the
> > regular Dell GUID (WMBA IIRC).  That's what is used to manipulate keyboard
> > LED timeouts in dell-laptop (although through direct SMI today).
> >
> > It's also what is used for other SMBIOS calls like changing random BIOS settings
> > that shouldn't be generically exposed in sysfs but should be controlled by
> > manageability tools.
> >
> > Example: turning on/off legacy option ROM or changing legacy boot order.
> >
> 
> IIUC we basically can't expose the SMI--based interface to this entry
> point to userspace because of its use of physical addressing.  It is
> reasonably safe to expose the WMI version?  (IOW should be expect that
> it doesn't enable kernel-mode or SMM code execution?)

The SMI based entry is already exposed using dcdbas.

The WMI version when executing a call that would be run as a SMI 
will copy the buffer to an area of memory that the BIOS has already 
been marked reserved to execute the SMI and copy the result out.

> 
> TBH, I've occasionally considered writing a driver to expose SMM code
> execution on systems with a known reliable exploit :)

On Dell HW?  I'm sure our security folks would be very interested in this.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-13 16:56   ` Darren Hart
@ 2017-04-13 20:38     ` Mario.Limonciello
  2017-04-13 23:51       ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-13 20:38 UTC (permalink / raw)
  To: dvhart, pali.rohar
  Cc: rjw, len.brown, corentin.chary, luto, andriy.shevchenko,
	linux-kernel, platform-driver-x86, linux-pm

Earlier question from Andy.  I had some discussion with the right people about this.

> Is it just the "call SMBIOS" GUID or are there other things?

Today - it's just the SMBIOS calling GUID.  There are plans (not yet concrete) for
splitting up data access and organization of that data access classes across multiple 
 other GUID/method pairs in the future.

Ideally this could be done without needing kernel patches every time a new GUID
would (essentially) need to be whitelisted.

> I am a strong supporter of the following philosophy with respect to supporting
> innovation:
> "Enable them to enable themselves and get out of their way"
> 
> I've followed this approach over the years to encourage upstream first software
> development, open-first policy toward specifications and documentation, proper
> license selection, and development of new mechanisms in existing standards, like
> ACPI _DSD. All of these serve to support innovation by removing bottlenecks and
> enabling developers to be independent.
> 
> What I don't want to see is the Linux kernel becoming a bottleneck to feature
> parity with Windows (or to becoming the lead vehicle for new features). When a
> vendor has a feature they want to expose which they determine to be a value
> proposition for their product, I don't want the lack of a class driver to get in
> the way. Exposing specific GUIDs is a minimal and easy to upstream change which
> would enable rapid feature enabling.
> 
> Perhaps I should have led with this :-)
> 

So considering future plans, I'd really like if it's possible to expose all the GUID's the
GUID's the same as Windows does today.

As example is we have some diagnostic testing tools.  Having to whitelist interfaces
for them to operate would be sub-optimal.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 20:38     ` Mario.Limonciello
@ 2017-04-13 23:51       ` Darren Hart
  2017-04-14 17:42         ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-04-13 23:51 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: pali.rohar, rjw, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Thu, Apr 13, 2017 at 08:38:28PM +0000, Mario.Limonciello@dell.com wrote:
> Earlier question from Andy.  I had some discussion with the right people about this.
> 
> > Is it just the "call SMBIOS" GUID or are there other things?
> 
> Today - it's just the SMBIOS calling GUID.  There are plans (not yet concrete) for
> splitting up data access and organization of that data access classes across multiple 
>  other GUID/method pairs in the future.
> 
> Ideally this could be done without needing kernel patches every time a new GUID
> would (essentially) need to be whitelisted.
> 
> > I am a strong supporter of the following philosophy with respect to supporting
> > innovation:
> > "Enable them to enable themselves and get out of their way"
> > 
> > I've followed this approach over the years to encourage upstream first software
> > development, open-first policy toward specifications and documentation, proper
> > license selection, and development of new mechanisms in existing standards, like
> > ACPI _DSD. All of these serve to support innovation by removing bottlenecks and
> > enabling developers to be independent.
> > 
> > What I don't want to see is the Linux kernel becoming a bottleneck to feature
> > parity with Windows (or to becoming the lead vehicle for new features). When a
> > vendor has a feature they want to expose which they determine to be a value
> > proposition for their product, I don't want the lack of a class driver to get in
> > the way. Exposing specific GUIDs is a minimal and easy to upstream change which
> > would enable rapid feature enabling.
> > 
> > Perhaps I should have led with this :-)
> > 
> 
> So considering future plans, I'd really like if it's possible to expose all the GUID's the
> GUID's the same as Windows does today.

A bit of trouble parsing... to be clear, your preference would be that for the
PNP0C14 on whitelisted platforms (either DMI matches, or possibly via the ACPI
Device UID?) we expose every GUID (Method, Event, and Data) for that device to
userspace?

The concern raised here is that for systems using dell-wmi, the two GUIDs used
by the kernel would also be exposed to userspace. Is this correct?

> 
> As example is we have some diagnostic testing tools.  Having to whitelist interfaces
> for them to operate would be sub-optimal.
> 

Is this a problem because there are a lot of them, or because they routinely
change?

Also, are these something that could be part of a debug feature, or do they need
to be in production so you can work with customers to diagnose running systems
for example?

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-13 23:51       ` Darren Hart
@ 2017-04-14 17:42         ` Mario.Limonciello
  2017-04-14 18:27           ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-14 17:42 UTC (permalink / raw)
  To: dvhart
  Cc: pali.rohar, rjw, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm



> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Thursday, April 13, 2017 6:51 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: pali.rohar@gmail.com; rjw@rjwysocki.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 Thu, Apr 13, 2017 at 08:38:28PM +0000, Mario.Limonciello@dell.com wrote:
> > Earlier question from Andy.  I had some discussion with the right people about
> this.
> >
> > > Is it just the "call SMBIOS" GUID or are there other things?
> >
> > Today - it's just the SMBIOS calling GUID.  There are plans (not yet concrete) for
> > splitting up data access and organization of that data access classes across
> multiple
> >  other GUID/method pairs in the future.
> >
> > Ideally this could be done without needing kernel patches every time a new GUID
> > would (essentially) need to be whitelisted.
> >
> > > I am a strong supporter of the following philosophy with respect to supporting
> > > innovation:
> > > "Enable them to enable themselves and get out of their way"
> > >
> > > I've followed this approach over the years to encourage upstream first software
> > > development, open-first policy toward specifications and documentation,
> proper
> > > license selection, and development of new mechanisms in existing standards,
> like
> > > ACPI _DSD. All of these serve to support innovation by removing bottlenecks
> and
> > > enabling developers to be independent.
> > >
> > > What I don't want to see is the Linux kernel becoming a bottleneck to feature
> > > parity with Windows (or to becoming the lead vehicle for new features). When a
> > > vendor has a feature they want to expose which they determine to be a value
> > > proposition for their product, I don't want the lack of a class driver to get in
> > > the way. Exposing specific GUIDs is a minimal and easy to upstream change
> which
> > > would enable rapid feature enabling.
> > >
> > > Perhaps I should have led with this :-)
> > >
> >
> > So considering future plans, I'd really like if it's possible to expose all the GUID's
> the
> > GUID's the same as Windows does today.
> 
> A bit of trouble parsing... to be clear, your preference would be that for the
> PNP0C14 on whitelisted platforms (either DMI matches, or possibly via the ACPI
> Device UID?) we expose every GUID (Method, Event, and Data) for that device to
> userspace?

My preference would be to expose everything found in _WDG across platforms so it 
doesn't have to be a whitelist.  DMI matching could work if it was done specifically
on the manufacturer rather than individual system.

If you compare to how it's done with the other OS, everything mentioned in the MOF
is accessible from userspace.  The only reason the MOF exists is to match up
what's in _WDG.  Linux can make this actually easier in that you just don't use the
MOF at all.

> 
> The concern raised here is that for systems using dell-wmi, the two GUIDs used
> by the kernel would also be exposed to userspace. Is this correct?
> 
> >
> > As example is we have some diagnostic testing tools.  Having to whitelist
> interfaces
> > for them to operate would be sub-optimal.
> >
> 
> Is this a problem because there are a lot of them, or because they routinely
> change?

They're going to be changing in the future and that will use a new WMI interface
when that change happens.

The interfaces don't routinely change today, but there discussions to change
and introduce more later.

> 
> Also, are these something that could be part of a debug feature, or do they need
> to be in production so you can work with customers to diagnose running systems
> for example?
> 

The intent is for production, so that remediation tools can run on the box.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-14 17:42         ` Mario.Limonciello
@ 2017-04-14 18:27           ` Darren Hart
  2017-04-14 19:04             ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-04-14 18:27 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: pali.rohar, rjw, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Fri, Apr 14, 2017 at 05:42:03PM +0000, Mario.Limonciello@dell.com wrote:
> 
> 
> > -----Original Message-----
> > From: Darren Hart [mailto:dvhart@infradead.org]
> > Sent: Thursday, April 13, 2017 6:51 PM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: pali.rohar@gmail.com; rjw@rjwysocki.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 Thu, Apr 13, 2017 at 08:38:28PM +0000, Mario.Limonciello@dell.com wrote:
> > > Earlier question from Andy.  I had some discussion with the right people about
> > this.
> > >
> > > > Is it just the "call SMBIOS" GUID or are there other things?
> > >
> > > Today - it's just the SMBIOS calling GUID.  There are plans (not yet concrete) for
> > > splitting up data access and organization of that data access classes across
> > multiple
> > >  other GUID/method pairs in the future.
> > >
> > > Ideally this could be done without needing kernel patches every time a new GUID
> > > would (essentially) need to be whitelisted.
> > >
> > > > I am a strong supporter of the following philosophy with respect to supporting
> > > > innovation:
> > > > "Enable them to enable themselves and get out of their way"
> > > >
> > > > I've followed this approach over the years to encourage upstream first software
> > > > development, open-first policy toward specifications and documentation,
> > proper
> > > > license selection, and development of new mechanisms in existing standards,
> > like
> > > > ACPI _DSD. All of these serve to support innovation by removing bottlenecks
> > and
> > > > enabling developers to be independent.
> > > >
> > > > What I don't want to see is the Linux kernel becoming a bottleneck to feature
> > > > parity with Windows (or to becoming the lead vehicle for new features). When a
> > > > vendor has a feature they want to expose which they determine to be a value
> > > > proposition for their product, I don't want the lack of a class driver to get in
> > > > the way. Exposing specific GUIDs is a minimal and easy to upstream change
> > which
> > > > would enable rapid feature enabling.
> > > >
> > > > Perhaps I should have led with this :-)
> > > >
> > >
> > > So considering future plans, I'd really like if it's possible to expose all the GUID's
> > the
> > > GUID's the same as Windows does today.
> > 
> > A bit of trouble parsing... to be clear, your preference would be that for the
> > PNP0C14 on whitelisted platforms (either DMI matches, or possibly via the ACPI
> > Device UID?) we expose every GUID (Method, Event, and Data) for that device to
> > userspace?
> 
> My preference would be to expose everything found in _WDG across platforms so it 
> doesn't have to be a whitelist.  DMI matching could work if it was done specifically
> on the manufacturer rather than individual system.
> 
> If you compare to how it's done with the other OS, everything mentioned in the MOF
> is accessible from userspace.  The only reason the MOF exists is to match up
> what's in _WDG.  Linux can make this actually easier in that you just don't use the
> MOF at all.
> 
> > 
> > The concern raised here is that for systems using dell-wmi, the two GUIDs used
> > by the kernel would also be exposed to userspace. Is this correct?

OK, rather than whitelisting specific GUIDs to be exported, what if we matched
on a vendor and exported all of them except for the ones that any kernel drivers
have already bound to? For example, dell-wmi currently binds to:

#define DELL_EVENT_GUID "9DBB5994-A997-11DA-B012-B622A1EF5492"
#define DELL_DESCRIPTOR_GUID "8D9DDCBC-A997-11DA-B012-B622A1EF5492"

Perhaps a set of mof and $vendor-mof drivers could be created which would do what
Andy L's patch does, but match on DMI Vendor or WMI PNP UID and export all
interfaces. When another kernel driver binds to a WMI GUID, that GUID will
either not be exported, or it will be "locked" from a userspace perspective.

This of course is dependent on whether or not the WMI GUIDs are granular enough
or if the same GUID is needed by the userpsace application AND by the kernel
driver to perform different functions - this would be really unfortunate.

That said, from what I've learned about WMI, it was designed to provide access
to firmware from userspace. The approach we take in Linux currently was
expedient, but not consistent with the intent of the mechanism.

> > 
> > >
> > > As example is we have some diagnostic testing tools.  Having to whitelist
> > interfaces
> > > for them to operate would be sub-optimal.
> > >
> > 
> > Is this a problem because there are a lot of them, or because they routinely
> > change?
> 
> They're going to be changing in the future and that will use a new WMI interface
> when that change happens.
> 
> The interfaces don't routinely change today, but there discussions to change
> and introduce more later.
> 
> > 
> > Also, are these something that could be part of a debug feature, or do they need
> > to be in production so you can work with customers to diagnose running systems
> > for example?
> > 
> 
> The intent is for production, so that remediation tools can run on the box.
> 
> 

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-14 18:27           ` Darren Hart
@ 2017-04-14 19:04             ` Mario.Limonciello
  0 siblings, 0 replies; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-14 19:04 UTC (permalink / raw)
  To: dvhart
  Cc: pali.rohar, rjw, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Friday, April 14, 2017 1:28 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: pali.rohar@gmail.com; rjw@rjwysocki.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 Fri, Apr 14, 2017 at 05:42:03PM +0000, Mario.Limonciello@dell.com wrote:
> >
> >
> > > -----Original Message-----
> > > From: Darren Hart [mailto:dvhart@infradead.org]
> > > Sent: Thursday, April 13, 2017 6:51 PM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: pali.rohar@gmail.com; rjw@rjwysocki.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 Thu, Apr 13, 2017 at 08:38:28PM +0000, Mario.Limonciello@dell.com
> wrote:
> > > > Earlier question from Andy.  I had some discussion with the right people about
> > > this.
> > > >
> > > > > Is it just the "call SMBIOS" GUID or are there other things?
> > > >
> > > > Today - it's just the SMBIOS calling GUID.  There are plans (not yet concrete)
> for
> > > > splitting up data access and organization of that data access classes across
> > > multiple
> > > >  other GUID/method pairs in the future.
> > > >
> > > > Ideally this could be done without needing kernel patches every time a new
> GUID
> > > > would (essentially) need to be whitelisted.
> > > >
> > > > > I am a strong supporter of the following philosophy with respect to
> supporting
> > > > > innovation:
> > > > > "Enable them to enable themselves and get out of their way"
> > > > >
> > > > > I've followed this approach over the years to encourage upstream first
> software
> > > > > development, open-first policy toward specifications and documentation,
> > > proper
> > > > > license selection, and development of new mechanisms in existing
> standards,
> > > like
> > > > > ACPI _DSD. All of these serve to support innovation by removing bottlenecks
> > > and
> > > > > enabling developers to be independent.
> > > > >
> > > > > What I don't want to see is the Linux kernel becoming a bottleneck to feature
> > > > > parity with Windows (or to becoming the lead vehicle for new features).
> When a
> > > > > vendor has a feature they want to expose which they determine to be a
> value
> > > > > proposition for their product, I don't want the lack of a class driver to get in
> > > > > the way. Exposing specific GUIDs is a minimal and easy to upstream change
> > > which
> > > > > would enable rapid feature enabling.
> > > > >
> > > > > Perhaps I should have led with this :-)
> > > > >
> > > >
> > > > So considering future plans, I'd really like if it's possible to expose all the
> GUID's
> > > the
> > > > GUID's the same as Windows does today.
> > >
> > > A bit of trouble parsing... to be clear, your preference would be that for the
> > > PNP0C14 on whitelisted platforms (either DMI matches, or possibly via the ACPI
> > > Device UID?) we expose every GUID (Method, Event, and Data) for that device to
> > > userspace?
> >
> > My preference would be to expose everything found in _WDG across platforms so
> it
> > doesn't have to be a whitelist.  DMI matching could work if it was done
> specifically
> > on the manufacturer rather than individual system.
> >
> > If you compare to how it's done with the other OS, everything mentioned in the
> MOF
> > is accessible from userspace.  The only reason the MOF exists is to match up
> > what's in _WDG.  Linux can make this actually easier in that you just don't use the
> > MOF at all.
> >
> > >
> > > The concern raised here is that for systems using dell-wmi, the two GUIDs used
> > > by the kernel would also be exposed to userspace. Is this correct?
> 
> OK, rather than whitelisting specific GUIDs to be exported, what if we matched
> on a vendor and exported all of them except for the ones that any kernel drivers
> have already bound to? For example, dell-wmi currently binds to:
> 
> #define DELL_EVENT_GUID "9DBB5994-A997-11DA-B012-B622A1EF5492"
> #define DELL_DESCRIPTOR_GUID "8D9DDCBC-A997-11DA-B012-B622A1EF5492"
> 
> Perhaps a set of mof and $vendor-mof drivers could be created which would do
> what
> Andy L's patch does, but match on DMI Vendor or WMI PNP UID and export all
> interfaces. When another kernel driver binds to a WMI GUID, that GUID will
> either not be exported, or it will be "locked" from a userspace perspective.
> 
> This of course is dependent on whether or not the WMI GUIDs are granular enough
> or if the same GUID is needed by the userpsace application AND by the kernel
> driver to perform different functions - this would be really unfortunate.
> 
> That said, from what I've learned about WMI, it was designed to provide access
> to firmware from userspace. The approach we take in Linux currently was
> expedient, but not consistent with the intent of the mechanism.
> 

For $FUTURE GUIDs that approach could potentially work depending upon how
the different GUID's are segmented.  There's a few different approaches being
discussed.

It unfortunately wouldn't work with the "current" stuff though if we go forward
with the proposal to adjust dell-smbios to use the WMI calls too.
The SMBIOS GUID(A80593CE-A997-11DA-B012-B622A1EF5492) would get 
taken by dell-smbios and hence not available to userspace.

It would be fine to restrict the event one (9DBB5994-A997-11DA-B012-B622A1EF5492).
The one the kernel sees as DESCRIPTOR_GUID can be used to provide static
Info, I don't think that's needed by userspace either.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-12 23:08 RFC: WMI Enhancements Darren Hart
  2017-04-13  7:32 ` Michał Kępień
  2017-04-13  7:33 ` Pali Rohár
@ 2017-04-14 22:45 ` Rafael J. Wysocki
  2017-04-14 23:05   ` Darren Hart
  2 siblings, 1 reply; 76+ messages in thread
From: Rafael J. Wysocki @ 2017-04-14 22:45 UTC (permalink / raw)
  To: Darren Hart
  Cc: Len Brown, Pali Rohár, Corentin Chary, Mario Limonciello,
	Andy Lutomirski, Andy Shevchenko, LKML, platform-driver-x86,
	linux-pm

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.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-14 22:45 ` Rafael J. Wysocki
@ 2017-04-14 23:05   ` Darren Hart
  2017-04-17 22:03     ` Andy Lutomirski
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-04-14 23:05 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Len Brown, Pali Rohár, Corentin Chary, Mario Limonciello,
	Andy Lutomirski, Andy Shevchenko, LKML, platform-driver-x86,
	linux-pm

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.

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-14 23:05   ` Darren Hart
@ 2017-04-17 22:03     ` Andy Lutomirski
  2017-04-17 23:10       ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Andy Lutomirski @ 2017-04-17 22:03 UTC (permalink / raw)
  To: Darren Hart
  Cc: Rafael J. Wysocki, Len Brown, Pali Rohár, Corentin Chary,
	Mario Limonciello, Andy Lutomirski, Andy Shevchenko, LKML,
	platform-driver-x86, linux-pm

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.

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.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-17 22:03     ` Andy Lutomirski
@ 2017-04-17 23:10       ` Darren Hart
  2017-04-18 13:07         ` Rafael J. Wysocki
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-04-17 23:10 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Rafael J. Wysocki, Len Brown, Pali Rohár, Corentin Chary,
	Mario Limonciello, Andy Lutomirski, Andy Shevchenko, LKML,
	platform-driver-x86, linux-pm

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.
> 
> 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.

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 15:40       ` Mario.Limonciello
@ 2017-04-18  7:36         ` Andy Shevchenko
  2017-04-18 14:08           ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Andy Shevchenko @ 2017-04-18  7:36 UTC (permalink / raw)
  To: Mario.Limonciello, pali.rohar, hdegoede
  Cc: kernel, dvhart, rjw, len.brown, corentin.chary, luto,
	linux-kernel, platform-driver-x86, linux-pm

On Thu, 2017-04-13 at 15:40 +0000, Mario.Limonciello@dell.com wrote:
> > libsmbios would benefit.
> > 
> > Really libsmbios matters here? Hans (added to thread) wrote that
> > libsmbios is
> > a relic, something of ages long gone by and a normal user should
> > never use it.
> > 	
> 
> A normal user shouldn't be using it directly, but libsmbios is used by
> a few open 
> source tools as a dependency.  It's also used in many Dell
> manageability tools.
> 

Shouldn't tools evolve to use newer interfaces (while keeping
compatibility with old kernels)?

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-13 17:39             ` Mario.Limonciello
  2017-04-13 17:44               ` Andy Lutomirski
@ 2017-04-18  7:54               ` Pali Rohár
  2017-04-18 16:56                 ` Darren Hart
  1 sibling, 1 reply; 76+ messages in thread
From: Pali Rohár @ 2017-04-18  7:54 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: dvhart, luto, kernel, rjw, len.brown, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Thursday 13 April 2017 17:39:56 Mario.Limonciello@dell.com wrote:
> > > No more than exists today with the dcdbas SMI interface (which
> > > only if you manually run userspace tools that manipulate the same
> > > data you can do that technically).
> > >
> > > We're all reasonable folks, if there is an instance of this that comes
> > > up we can make changes to userspace to fix it.
> > 
> > Right. As Pali pointed out previously, if there is an existing class driver /
> > subsystem which supports this functionality we should use that.
> > 
> > I suppose one risk will be one GUID exposing both types of methods. Those which
> > are used by kernel drivers, and those which have no kernel support. Or worse,
> > methods which have multiple behaviors depending on their input arguments.
> > 
> > --
> 
> Well the "most" interesting to me is the SMBIOS calling interface on the
> regular Dell GUID (WMBA IIRC).  That's what is used to manipulate keyboard
> LED timeouts in dell-laptop (although through direct SMI today).
> 
> It's also what is used for other SMBIOS calls like changing random BIOS settings
> that shouldn't be generically exposed in sysfs but should be controlled by
> manageability tools.
> 
> Example: turning on/off legacy option ROM or changing legacy boot order.

Which basically means that new WMI /dev/ files does not help for Dell.

Kernel needs to manipulate with SMBIOS for implementing rfkill, keyboard
backlight, display brightness and also needs to receive WMI events for
hotkeys. So kernel modules would lock WMI interface for receiving events
& sending SMBIOS calls, and userspace would be blocked from usage of
this WMI GUID.

I do not think that we can solve this problem easily in vendor-neutral
interface. There was argument that WMI API was designed to allow
userspace applications call firmware functions directly... But we are
using WMI in kernel and we should not allow both kernel and userspace to
fight on some WMI API.

So for Dell we need for sure some Dell specific interface which covers
all needed functionality. I'm not sure what everything Dell software
needs, so what about specifying current usage of Dell SMBIOS/WMI
functions from existing userspace applications and also planned usage in
future? Then from this information we can design kernel and userspace
API which can fit for Dell usage.

About other vendor WMI's functions... I'm not sure, but there is again
possibility that rfkill, leds or hotkeys would exists on same WMI GUID
as other maintenance functions (which userspace wants), so export would
be again blocked by kernel module for rfkill/leds/hotkeys.

Therefore I'm not really sure if some /dev/wmi* API would be usefull,
and not always blocked by kernel module which implements rfkill support.

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-17 23:10       ` Darren Hart
@ 2017-04-18 13:07         ` Rafael J. Wysocki
  2017-04-18 16:33           ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Rafael J. Wysocki @ 2017-04-18 13:07 UTC (permalink / raw)
  To: Darren Hart, Andy Lutomirski
  Cc: Len Brown, Pali Rohár, Corentin Chary, Mario Limonciello,
	Andy Lutomirski, Andy Shevchenko, LKML, platform-driver-x86,
	linux-pm

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.

> > 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).

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-18  7:36         ` Andy Shevchenko
@ 2017-04-18 14:08           ` Mario.Limonciello
  0 siblings, 0 replies; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-18 14:08 UTC (permalink / raw)
  To: andriy.shevchenko, pali.rohar, hdegoede
  Cc: kernel, dvhart, rjw, len.brown, corentin.chary, luto,
	linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Andy Shevchenko [mailto:andriy.shevchenko@linux.intel.com]
> Sent: Tuesday, April 18, 2017 2:37 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>; pali.rohar@gmail.com;
> hdegoede@redhat.com
> Cc: kernel@kempniu.pl; dvhart@infradead.org; rjw@rjwysocki.net;
> len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org; linux-
> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org; linux-
> pm@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Thu, 2017-04-13 at 15:40 +0000, Mario.Limonciello@dell.com wrote:
> > > libsmbios would benefit.
> > >
> > > Really libsmbios matters here? Hans (added to thread) wrote that
> > > libsmbios is
> > > a relic, something of ages long gone by and a normal user should
> > > never use it.
> > >
> >
> > A normal user shouldn't be using it directly, but libsmbios is used by
> > a few open
> > source tools as a dependency.  It's also used in many Dell
> > manageability tools.
> >
> 
> Shouldn't tools evolve to use newer interfaces (while keeping
> compatibility with old kernels)?

Yes.  If a WMI userspace interface does end up being the outcome of
this thread, I'll push the relevant folks maintaining those tools to switch
over so that dcdbas can be marked deprecated and only in use for older
kernels.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-18 13:07         ` Rafael J. Wysocki
@ 2017-04-18 16:33           ` Darren Hart
  2017-04-18 19:28             ` Pali Rohár
  2017-04-18 21:14             ` Rafael J. Wysocki
  0 siblings, 2 replies; 76+ messages in thread
From: Darren Hart @ 2017-04-18 16:33 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Andy Lutomirski, Len Brown, Pali Rohár, Corentin Chary,
	Mario Limonciello, Andy Lutomirski, Andy Shevchenko, LKML,
	platform-driver-x86, linux-pm

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-18  7:54               ` Pali Rohár
@ 2017-04-18 16:56                 ` Darren Hart
  2017-04-18 19:28                   ` Pali Rohár
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-04-18 16:56 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Mario.Limonciello, luto, kernel, rjw, len.brown, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Tue, Apr 18, 2017 at 09:54:01AM +0200, Pali Rohár wrote:
> On Thursday 13 April 2017 17:39:56 Mario.Limonciello@dell.com wrote:
> > > > No more than exists today with the dcdbas SMI interface (which
> > > > only if you manually run userspace tools that manipulate the same
> > > > data you can do that technically).
> > > >
> > > > We're all reasonable folks, if there is an instance of this that comes
> > > > up we can make changes to userspace to fix it.
> > > 
> > > Right. As Pali pointed out previously, if there is an existing class driver /
> > > subsystem which supports this functionality we should use that.
> > > 
> > > I suppose one risk will be one GUID exposing both types of methods. Those which
> > > are used by kernel drivers, and those which have no kernel support. Or worse,
> > > methods which have multiple behaviors depending on their input arguments.
> > > 
> > > --
> > 
> > Well the "most" interesting to me is the SMBIOS calling interface on the
> > regular Dell GUID (WMBA IIRC).  That's what is used to manipulate keyboard
> > LED timeouts in dell-laptop (although through direct SMI today).
> > 
> > It's also what is used for other SMBIOS calls like changing random BIOS settings
> > that shouldn't be generically exposed in sysfs but should be controlled by
> > manageability tools.
> > 
> > Example: turning on/off legacy option ROM or changing legacy boot order.
> 
> Which basically means that new WMI /dev/ files does not help for Dell.
> 
> Kernel needs to manipulate with SMBIOS for implementing rfkill, keyboard
> backlight, display brightness and also needs to receive WMI events for
> hotkeys. So kernel modules would lock WMI interface for receiving events
> & sending SMBIOS calls, and userspace would be blocked from usage of
> this WMI GUID.

This is why we can't rely on a method ID granular filter for which methods are
exported to userspace. In my previous reply to Rafael, I suggested platform
drivers decide which method IDs are exported, and for platforms with
insufficient WMI method ID granularity, we will end up exposing methods we also
use in the kernel. The WMI evaluation will need to be centralized and placed
under mutual exclusion. The optional wmi evaluation filter would allow for
drivers to audit incoming calls from userspace to ensure no conflict.

It's not ideal - but I believe it addresses our reality.

> 
> I do not think that we can solve this problem easily in vendor-neutral
> interface. There was argument that WMI API was designed to allow
> userspace applications call firmware functions directly... But we are
> using WMI in kernel and we should not allow both kernel and userspace to
> fight on some WMI API.

We could drop all the in kernel wmi drivers and rely on userspace daemons per
platform.... but I think we all agree that is not where we want this to go. So
we'll need to find a compromise. Even then, we'd need to avoid competition for
common method IDs across multiple userspace applications.

> 
> So for Dell we need for sure some Dell specific interface which covers
> all needed functionality. I'm not sure what everything Dell software
> needs, so what about specifying current usage of Dell SMBIOS/WMI
> functions from existing userspace applications and also planned usage in
> future? Then from this information we can design kernel and userspace
> API which can fit for Dell usage.

This was my initial response as well. The biggest problem with it is it places
Linux imposed restrictions on the WMI mechanism, which will ultimately stifle
innovation and/or leave Linux as a second class citizen for systems which rely
on WMI for userspace firmware management.

> 
> About other vendor WMI's functions... I'm not sure, but there is again
> possibility that rfkill, leds or hotkeys would exists on same WMI GUID
> as other maintenance functions (which userspace wants), so export would
> be again blocked by kernel module for rfkill/leds/hotkeys.
> 
> Therefore I'm not really sure if some /dev/wmi* API would be usefull,
> and not always blocked by kernel module which implements rfkill support.

I'd like to also point out that the Linux kernel has a minimal and targeted set
of WMI drivers generally aimed at making laptops work as expected through the
only mechanism we had access to. To my knowledge, we never sat down to discuss
how WMI should be implemented in the Linux ecosystem. That leaves us in the
situation we are in today, in which Linux essentially took the most expedient
route to making laptops work - which happened to be WMI, but we didn't consider
the broader implications of that mechanism or how what we implemented would
interact with full set of functionality provided by WMI.

So our challenge now is to look at WMI as a whole. How should it be implemented
to achieve feature parity. And then consider how the existing drivers fit into
that. Please see my proposal in response to Rafael's latest reply. I believe it
outlines a reasonable compromise.

Thanks,

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-18 16:56                 ` Darren Hart
@ 2017-04-18 19:28                   ` Pali Rohár
  0 siblings, 0 replies; 76+ messages in thread
From: Pali Rohár @ 2017-04-18 19:28 UTC (permalink / raw)
  To: Darren Hart
  Cc: Mario.Limonciello, luto, kernel, rjw, len.brown, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

[-- Attachment #1: Type: Text/Plain, Size: 7447 bytes --]

On Tuesday 18 April 2017 18:56:31 Darren Hart wrote:
> On Tue, Apr 18, 2017 at 09:54:01AM +0200, Pali Rohár wrote:
> > On Thursday 13 April 2017 17:39:56 Mario.Limonciello@dell.com wrote:
> > > > > No more than exists today with the dcdbas SMI interface
> > > > > (which only if you manually run userspace tools that
> > > > > manipulate the same data you can do that technically).
> > > > > 
> > > > > We're all reasonable folks, if there is an instance of this
> > > > > that comes up we can make changes to userspace to fix it.
> > > > 
> > > > Right. As Pali pointed out previously, if there is an existing
> > > > class driver / subsystem which supports this functionality we
> > > > should use that.
> > > > 
> > > > I suppose one risk will be one GUID exposing both types of
> > > > methods. Those which are used by kernel drivers, and those
> > > > which have no kernel support. Or worse, methods which have
> > > > multiple behaviors depending on their input arguments.
> > > > 
> > > > --
> > > 
> > > Well the "most" interesting to me is the SMBIOS calling interface
> > > on the regular Dell GUID (WMBA IIRC).  That's what is used to
> > > manipulate keyboard LED timeouts in dell-laptop (although
> > > through direct SMI today).
> > > 
> > > It's also what is used for other SMBIOS calls like changing
> > > random BIOS settings that shouldn't be generically exposed in
> > > sysfs but should be controlled by manageability tools.
> > > 
> > > Example: turning on/off legacy option ROM or changing legacy boot
> > > order.
> > 
> > Which basically means that new WMI /dev/ files does not help for
> > Dell.
> > 
> > Kernel needs to manipulate with SMBIOS for implementing rfkill,
> > keyboard backlight, display brightness and also needs to receive
> > WMI events for hotkeys. So kernel modules would lock WMI interface
> > for receiving events & sending SMBIOS calls, and userspace would
> > be blocked from usage of this WMI GUID.
> 
> This is why we can't rely on a method ID granular filter for which
> methods are exported to userspace. In my previous reply to Rafael, I
> suggested platform drivers decide which method IDs are exported, and
> for platforms with insufficient WMI method ID granularity, we will
> end up exposing methods we also use in the kernel. The WMI
> evaluation will need to be centralized and placed under mutual
> exclusion. The optional wmi evaluation filter would allow for
> drivers to audit incoming calls from userspace to ensure no
> conflict.
> 
> It's not ideal - but I believe it addresses our reality.

Ok.

> > I do not think that we can solve this problem easily in
> > vendor-neutral interface. There was argument that WMI API was
> > designed to allow userspace applications call firmware functions
> > directly... But we are using WMI in kernel and we should not allow
> > both kernel and userspace to fight on some WMI API.
> 
> We could drop all the in kernel wmi drivers and rely on userspace
> daemons per platform.... but I think we all agree that is not where
> we want this to go. So we'll need to find a compromise. Even then,
> we'd need to avoid competition for common method IDs across multiple
> userspace applications.

I think this is step backward. Current wmi drivers in kernel which 
implements class devices should stay in kernel -- independently of fact 
if they are provided by WMI API, ACPI API or direct HW access.

> > So for Dell we need for sure some Dell specific interface which
> > covers all needed functionality. I'm not sure what everything Dell
> > software needs, so what about specifying current usage of Dell
> > SMBIOS/WMI functions from existing userspace applications and also
> > planned usage in future? Then from this information we can design
> > kernel and userspace API which can fit for Dell usage.
> 
> This was my initial response as well. The biggest problem with it is
> it places Linux imposed restrictions on the WMI mechanism, which
> will ultimately stifle innovation and/or leave Linux as a second
> class citizen for systems which rely on WMI for userspace firmware
> management.

Maybe... I agree that having WMI API for userspace application could be 
useful, but it should not be at cost of loosing current kernel drivers 
or kernel functionality provided by current kernel wmi drivers.

The question is, who is interested in full WMI access from userspace? 
And who already requested it in past? I'm just asking if we are not 
going to work on something in which nobody is interested...

Yes, we know from Mario that Dell is interested in WMI access from 
userspace. But is there other vendor? At least I do not know, so this is 
reason why I suggested to rather create API specially for Dell which 
will fully fit for both userspace Dell applications and also kernel dell 
wmi drivers to minimize conflicts.

I'm sure that specific API/ABI designed for concrete usage (here in 
Dell) would be easier and also better in resolving conflicts and 
fighting between kernel & userspace as some fully generic API/ABI which 
needs to be designed for everything and everybody.

What worry me is that there will be kernel wmi drivers which due to 
conflicts in locking/usage would not be able to allow userspace to 
access WMI. Or if their implemented filter would not fullfit for vendor 
userspace application (for some reasons), and vendor userspace 
application starts blocking kernel wmi modules. This would mean that 
user would be in position where must decide if he wants: stable kernel 
driver for controlling rfkill/led and receive hotkey presses OR 
userspace application which can control charging, setting special BIOS 
settings/etc/... And if laptop vendors do not want to coordinate work 
with kernel upstream, this situation can really happen.

> > About other vendor WMI's functions... I'm not sure, but there is
> > again possibility that rfkill, leds or hotkeys would exists on
> > same WMI GUID as other maintenance functions (which userspace
> > wants), so export would be again blocked by kernel module for
> > rfkill/leds/hotkeys.
> > 
> > Therefore I'm not really sure if some /dev/wmi* API would be
> > usefull, and not always blocked by kernel module which implements
> > rfkill support.
> 
> I'd like to also point out that the Linux kernel has a minimal and
> targeted set of WMI drivers generally aimed at making laptops work
> as expected through the only mechanism we had access to.

Yes, that is truth for obvious reason.

> To my
> knowledge, we never sat down to discuss how WMI should be
> implemented in the Linux ecosystem. That leaves us in the situation
> we are in today, in which Linux essentially took the most expedient
> route to making laptops work - which happened to be WMI, but we
> didn't consider the broader implications of that mechanism or how
> what we implemented would interact with full set of functionality
> provided by WMI.

I did not know about any discussion too.

> So our challenge now is to look at WMI as a whole. How should it be
> implemented to achieve feature parity. And then consider how the
> existing drivers fit into that. Please see my proposal in response
> to Rafael's latest reply. I believe it outlines a reasonable
> compromise.

Ok, I will write there other notes.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-18 16:33           ` Darren Hart
@ 2017-04-18 19:28             ` Pali Rohár
  2017-04-18 22:49               ` Darren Hart
  2017-04-18 21:14             ` Rafael J. Wysocki
  1 sibling, 1 reply; 76+ messages in thread
From: Pali Rohár @ 2017-04-18 19:28 UTC (permalink / raw)
  To: Darren Hart
  Cc: Rafael J. Wysocki, Andy Lutomirski, Len Brown, Corentin Chary,
	Mario Limonciello, Andy Lutomirski, Andy Shevchenko, LKML,
	platform-driver-x86, linux-pm

[-- Attachment #1: Type: Text/Plain, Size: 10412 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-18 16:33           ` Darren Hart
  2017-04-18 19:28             ` Pali Rohár
@ 2017-04-18 21:14             ` Rafael J. Wysocki
  1 sibling, 0 replies; 76+ messages in thread
From: Rafael J. Wysocki @ 2017-04-18 21:14 UTC (permalink / raw)
  To: Darren Hart
  Cc: Rafael J. Wysocki, Andy Lutomirski, Len Brown, Pali Rohár,
	Corentin Chary, Mario Limonciello, Andy Lutomirski,
	Andy Shevchenko, LKML, platform-driver-x86, linux-pm

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-18 19:28             ` Pali Rohár
@ 2017-04-18 22:49               ` Darren Hart
  2017-04-19  7:52                 ` Pali Rohár
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-04-18 22:49 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Rafael J. Wysocki, Andy Lutomirski, Len Brown, Corentin Chary,
	Mario Limonciello, Andy Lutomirski, Andy Shevchenko, LKML,
	platform-driver-x86, linux-pm

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-18 22:49               ` Darren Hart
@ 2017-04-19  7:52                 ` Pali Rohár
  2017-04-19 16:29                   ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Pali Rohár @ 2017-04-19  7:52 UTC (permalink / raw)
  To: Darren Hart
  Cc: Rafael J. Wysocki, Andy Lutomirski, Len Brown, Corentin Chary,
	Mario Limonciello, Andy Lutomirski, Andy Shevchenko, LKML,
	platform-driver-x86, linux-pm

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-19  7:52                 ` Pali Rohár
@ 2017-04-19 16:29                   ` Mario.Limonciello
  2017-04-19 16:54                     ` Pali Rohár
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-19 16:29 UTC (permalink / raw)
  To: pali.rohar, dvhart
  Cc: rjw, luto, len.brown, corentin.chary, luto, andriy.shevchenko,
	linux-kernel, platform-driver-x86, linux-pm

> -----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.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-19 16:29                   ` Mario.Limonciello
@ 2017-04-19 16:54                     ` Pali Rohár
  2017-04-19 17:24                       ` Mario.Limonciello
  2017-04-20 14:17                       ` Christoph Hellwig
  0 siblings, 2 replies; 76+ messages in thread
From: Pali Rohár @ 2017-04-19 16:54 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

[-- Attachment #1: Type: Text/Plain, Size: 1378 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-19 16:54                     ` Pali Rohár
@ 2017-04-19 17:24                       ` Mario.Limonciello
  2017-04-20 13:14                         ` Pali Rohár
  2017-04-20 14:17                       ` Christoph Hellwig
  1 sibling, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-04-19 17:24 UTC (permalink / raw)
  To: pali.rohar
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----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).

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-19 17:24                       ` Mario.Limonciello
@ 2017-04-20 13:14                         ` Pali Rohár
  2017-04-20 20:44                           ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Pali Rohár @ 2017-04-20 13:14 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-19 16:54                     ` Pali Rohár
  2017-04-19 17:24                       ` Mario.Limonciello
@ 2017-04-20 14:17                       ` Christoph Hellwig
  1 sibling, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2017-04-20 14:17 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Mario.Limonciello, dvhart, rjw, luto, len.brown, corentin.chary,
	luto, andriy.shevchenko, linux-kernel, platform-driver-x86,
	linux-pm

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.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-04-20 13:14                         ` Pali Rohár
@ 2017-04-20 20:44                           ` Darren Hart
  2017-05-05 21:55                             ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-04-20 20:44 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Mario.Limonciello, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-04-20 20:44                           ` Darren Hart
@ 2017-05-05 21:55                             ` Mario.Limonciello
  2017-05-05 23:44                               ` Darren Hart
  2017-05-08 17:17                               ` Pali Rohár
  0 siblings, 2 replies; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-05 21:55 UTC (permalink / raw)
  To: dvhart, pali.rohar
  Cc: rjw, luto, len.brown, corentin.chary, luto, andriy.shevchenko,
	linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Thursday, April 20, 2017 3:45 PM
> To: Pali Rohár <pali.rohar@gmail.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; 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 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.
> 

There are other examples in the kernel of the same data accessible in multiple
different methods that can cause inconsistencies too.

> > 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.

To get this started can you re-review Andy's platform/wmi tree and merge in some
of his bus work?  Regardless of the outcome of the access to userspace and dynamic
binding this is a good direction for WMI support in platform/drivers/x86 to get started.

> 
> 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.
> 

I've been studying more about how this access to WMI BIOS functions on Windows
works this week and uncovered what I see as another set of related questions around
commitment to manageability access from the OS with this potential userspace layer.

On Windows what happens is the MOF data (same stuff exposed by Andy's wmi-mof)
is imported into the WMI namespace.  This allows any tools to know exactly how
to interact with the various GUID's associated to the ASL methods.  The format of the
data and the arguments supported are encoded directly in that MOF data.

This means that standard WBEM tools are able to interact directly with these methods
based upon exposed objects.  BIOS manufacturer can expose say all BIOS settings that 
are integer to a GUID for interacting with integer settings and those would get loaded 
into the WMI namespace.  When someone uses a WBEM tool to modify that object
the data is properly formatted into the correct arguments for an integer and then run 
through the ASL.  Another GUID might be made for strings and another for specially
crafted lists (like a boot order).  The important part is that all settings are discoverable
and no extra tools are needed to administer a box.  It can all be done from things like 
PowerShell or wmic.

In an ideal world I think this is the right solution for Linux too, as part of this pipe we've
discussed let some userspace Linux WBEM tools like OpenLMI have access to a BIOS
provider that can interact with various settings.

Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF" which
has been pre-compiled to an intermediate format with mofcomp.exe on Windows.
The format of binary MOF is not documented and the only known way to get text 
mof back out is by using mofcomp.exe with some esoteric arguments.

mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409 binary_mof_file

So with that said, what role should the Linux kernel actually play here?

My thought is it still makes sense to make this pipe available to potentially enable WBEM
tools at some point.  At least until a way to deconstruct binary MOF is made available,
it's conceivable to build a provider from reverse engineered discovery of how the ASL works,
it just won't be as "pretty" as the type of data you get out of MOF with name and value mappings.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-05 21:55                             ` Mario.Limonciello
@ 2017-05-05 23:44                               ` Darren Hart
  2017-05-06  0:51                                 ` Mario.Limonciello
  2017-05-08 17:17                               ` Pali Rohár
  1 sibling, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-05-05 23:44 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: pali.rohar, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Fri, May 05, 2017 at 09:55:46PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Darren Hart [mailto:dvhart@infradead.org]
> > Sent: Thursday, April 20, 2017 3:45 PM
> > To: Pali Rohár <pali.rohar@gmail.com>
> > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; 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 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.
> > 
> 
> There are other examples in the kernel of the same data accessible in multiple
> different methods that can cause inconsistencies too.

Something that occurred to me today is we could include in the API of the WMI
device the potential return of -EBUSY anytime the kernel decides it can't safely
service a call. This would avoid *changing* the API exposed to userspace, but it
could change the behavior and availability of certain methods.

> 
> > > 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.
> 
> To get this started can you re-review Andy's platform/wmi tree and merge in some
> of his bus work?  Regardless of the outcome of the access to userspace and dynamic
> binding this is a good direction for WMI support in platform/drivers/x86 to get started.

Yes, this is already queued up for next week, and will be targeted at the 4.13
merge window.

> 
> > 
> > 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.
> > 
> 
> I've been studying more about how this access to WMI BIOS functions on Windows
> works this week and uncovered what I see as another set of related questions around
> commitment to manageability access from the OS with this potential userspace layer.
> 
> On Windows what happens is the MOF data (same stuff exposed by Andy's wmi-mof)
> is imported into the WMI namespace.  This allows any tools to know exactly how
> to interact with the various GUID's associated to the ASL methods.  The format of the
> data and the arguments supported are encoded directly in that MOF data.
> 
> This means that standard WBEM tools are able to interact directly with these methods
> based upon exposed objects.  BIOS manufacturer can expose say all BIOS settings that 
> are integer to a GUID for interacting with integer settings and those would get loaded 
> into the WMI namespace.  When someone uses a WBEM tool to modify that object
> the data is properly formatted into the correct arguments for an integer and then run 
> through the ASL.  Another GUID might be made for strings and another for specially
> crafted lists (like a boot order).  The important part is that all settings are discoverable
> and no extra tools are needed to administer a box.  It can all be done from things like 
> PowerShell or wmic.

Ah, that's good insight, thank you.

> 
> In an ideal world I think this is the right solution for Linux too, as part of this pipe we've
> discussed let some userspace Linux WBEM tools like OpenLMI have access to a BIOS
> provider that can interact with various settings.
> 
> Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF" which
> has been pre-compiled to an intermediate format with mofcomp.exe on Windows.
> The format of binary MOF is not documented and the only known way to get text 
> mof back out is by using mofcomp.exe with some esoteric arguments.
> 
> mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409 binary_mof_file
> 

Oh wow. That's... that's just horrible. :-(

Do you have an idea as to the relative complexity of this format? Does it make
sense for us to attempt to decompile it? Presumably this would be done in
userspace ... although seeing as how we have drivers using this functionality,
it would be useful to be able to parse this from the kernel as well. Hrm.

Definitely *not* a perfect world :-)

> So with that said, what role should the Linux kernel actually play here?

Time to level this up. I'll draft something up and try to get Linus and Greg to
weigh in.

> My thought is it still makes sense to make this pipe available to potentially enable WBEM
> tools at some point.  At least until a way to deconstruct binary MOF is made available,
> it's conceivable to build a provider from reverse engineered discovery of how the ASL works,
> it just won't be as "pretty" as the type of data you get out of MOF with name and value mappings.

I'm not following the "At least until a way to deconstruct binary MOF is made
available" relates to making the pipe as you called it available?

The pipe would provide a WMI chardev which usespace could open and write a
method ID and arguments to, and read a response. That is necessary whether or
not the MOF data is legible. Having the MOF data just means it's less work to
figure out exactly which method IDs are available and what arguments they
accept. Right?

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-05-05 23:44                               ` Darren Hart
@ 2017-05-06  0:51                                 ` Mario.Limonciello
  2017-05-06  1:25                                   ` Andy Lutomirski
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-06  0:51 UTC (permalink / raw)
  To: dvhart
  Cc: pali.rohar, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Friday, May 5, 2017 6:45 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: pali.rohar@gmail.com; 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 Fri, May 05, 2017 at 09:55:46PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Darren Hart [mailto:dvhart@infradead.org]
> > > Sent: Thursday, April 20, 2017 3:45 PM
> > > To: Pali Rohár <pali.rohar@gmail.com>
> > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; 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 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.
> > >
> >
> > There are other examples in the kernel of the same data accessible in multiple
> > different methods that can cause inconsistencies too.
> 
> Something that occurred to me today is we could include in the API of the WMI
> device the potential return of -EBUSY anytime the kernel decides it can't safely
> service a call. This would avoid *changing* the API exposed to userspace, but it
> could change the behavior and availability of certain methods.
> 
> >
> > > > 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.
> >
> > To get this started can you re-review Andy's platform/wmi tree and merge in
> some
> > of his bus work?  Regardless of the outcome of the access to userspace and
> dynamic
> > binding this is a good direction for WMI support in platform/drivers/x86 to get
> started.
> 
> Yes, this is already queued up for next week, and will be targeted at the 4.13
> merge window.
> 

OK great.

> >
> > >
> > > 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.
> > >
> >
> > I've been studying more about how this access to WMI BIOS functions on
> Windows
> > works this week and uncovered what I see as another set of related questions
> around
> > commitment to manageability access from the OS with this potential userspace
> layer.
> >
> > On Windows what happens is the MOF data (same stuff exposed by Andy's wmi-
> mof)
> > is imported into the WMI namespace.  This allows any tools to know exactly how
> > to interact with the various GUID's associated to the ASL methods.  The format of
> the
> > data and the arguments supported are encoded directly in that MOF data.
> >
> > This means that standard WBEM tools are able to interact directly with these
> methods
> > based upon exposed objects.  BIOS manufacturer can expose say all BIOS settings
> that
> > are integer to a GUID for interacting with integer settings and those would get
> loaded
> > into the WMI namespace.  When someone uses a WBEM tool to modify that
> object
> > the data is properly formatted into the correct arguments for an integer and then
> run
> > through the ASL.  Another GUID might be made for strings and another for
> specially
> > crafted lists (like a boot order).  The important part is that all settings are
> discoverable
> > and no extra tools are needed to administer a box.  It can all be done from things
> like
> > PowerShell or wmic.
> 
> Ah, that's good insight, thank you.
> 
> >
> > In an ideal world I think this is the right solution for Linux too, as part of this pipe
> we've
> > discussed let some userspace Linux WBEM tools like OpenLMI have access to a
> BIOS
> > provider that can interact with various settings.
> >
> > Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF"
> which
> > has been pre-compiled to an intermediate format with mofcomp.exe on
> Windows.
> > The format of binary MOF is not documented and the only known way to get text
> > mof back out is by using mofcomp.exe with some esoteric arguments.
> >
> > mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
> binary_mof_file
> >
> 
> Oh wow. That's... that's just horrible. :-(

That's only because a researcher discovered it too.  MS doesn't formally provide
any documented support for extracting from binary MOF.

> 
> Do you have an idea as to the relative complexity of this format? Does it make
> sense for us to attempt to decompile it? Presumably this would be done in
> userspace ... although seeing as how we have drivers using this functionality,
> it would be useful to be able to parse this from the kernel as well. Hrm.
> 

I haven't done any analysis of it so I'm not really sure how complex it will be.
For now I'd say userspace should be planned to handle it until someone determines
A simple enough way to decompile it that can live in the kernel.

> Definitely *not* a perfect world :-)
> 
> > So with that said, what role should the Linux kernel actually play here?
> 
> Time to level this up. I'll draft something up and try to get Linus and Greg to
> weigh in.

OK thanks.

> 
> > My thought is it still makes sense to make this pipe available to potentially enable
> WBEM
> > tools at some point.  At least until a way to deconstruct binary MOF is made
> available,
> > it's conceivable to build a provider from reverse engineered discovery of how the
> ASL works,
> > it just won't be as "pretty" as the type of data you get out of MOF with name and
> value mappings.
> 
> I'm not following the "At least until a way to deconstruct binary MOF is made
> available" relates to making the pipe as you called it available?
> 
> The pipe would provide a WMI chardev which usespace could open and write a
> method ID and arguments to, and read a response. That is necessary whether or
> not the MOF data is legible. Having the MOF data just means it's less work to
> figure out exactly which method IDs are available and what arguments they
> accept. Right?
> 

I meant that to say that at least for now Andy's wmi-mof driver should still be merged.
If something is going to build on top of this to do WBEM tools, they'll need that MOF
data once someone figures out how to nicely deconstruct it.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-06  0:51                                 ` Mario.Limonciello
@ 2017-05-06  1:25                                   ` Andy Lutomirski
  2017-05-08 15:29                                     ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Andy Lutomirski @ 2017-05-06  1:25 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: Darren Hart, Pali Rohár, Rafael J. Wysocki, Len Brown,
	Corentin Chary, Andrew Lutomirski, Andy Shevchenko, linux-kernel,
	platform-driver-x86, linux-pm

On Fri, May 5, 2017 at 5:51 PM,  <Mario.Limonciello@dell.com> wrote:
>> -----Original Message-----
>> From: Darren Hart [mailto:dvhart@infradead.org]
>> Sent: Friday, May 5, 2017 6:45 PM
>> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
>> Cc: pali.rohar@gmail.com; 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


> I meant that to say that at least for now Andy's wmi-mof driver should still be merged.
> If something is going to build on top of this to do WBEM tools, they'll need that MOF
> data once someone figures out how to nicely deconstruct it.
>

The thing I don't like about my own driver is that, as a WMI device
driver, it can be loaded before the rest of the bus finishes probing.
So user programs that are notified asynchronously that the wmi-mof
driver is loaded and try to use future functionality (ioctl to issue a
MOF-based method call?) might end up doing so before the rest of the
bus is probed.

This could be addressed by always exposing the wmi-mof device last
(sort of -- it can be a module) or perhaps by moving MOF functionality
to the core driver.  Or maybe it's not really a problem.

Also, isn't there a way to ask Microsoft to document this?  Are you
supposed to "ask a question" on this forum, perhaps:

https://msdn.microsoft.com/en-us/library/gg134029.aspx

I'm guessing the Samba team knows how to do this, too.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-06  1:25                                   ` Andy Lutomirski
@ 2017-05-08 15:29                                     ` Darren Hart
  2017-05-08 15:36                                       ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-05-08 15:29 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Mario.Limonciello, Pali Rohár, Rafael J. Wysocki, Len Brown,
	Corentin Chary, Andy Shevchenko, linux-kernel,
	platform-driver-x86, linux-pm

On Fri, May 05, 2017 at 06:25:08PM -0700, Andy Lutomirski wrote:
> On Fri, May 5, 2017 at 5:51 PM,  <Mario.Limonciello@dell.com> wrote:
> >> -----Original Message-----
> >> From: Darren Hart [mailto:dvhart@infradead.org]
> >> Sent: Friday, May 5, 2017 6:45 PM
> >> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> >> Cc: pali.rohar@gmail.com; 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
> 
> 
> > I meant that to say that at least for now Andy's wmi-mof driver should still be merged.
> > If something is going to build on top of this to do WBEM tools, they'll need that MOF
> > data once someone figures out how to nicely deconstruct it.
> >
> 
> The thing I don't like about my own driver is that, as a WMI device
> driver, it can be loaded before the rest of the bus finishes probing.
> So user programs that are notified asynchronously that the wmi-mof
> driver is loaded and try to use future functionality (ioctl to issue a
> MOF-based method call?) might end up doing so before the rest of the
> bus is probed.
> 
> This could be addressed by always exposing the wmi-mof device last
> (sort of -- it can be a module) or perhaps by moving MOF functionality
> to the core driver.  Or maybe it's not really a problem.

Thanks Andy, I'll keep that in mind and see if I can come up with something to
address it while working on WMI this week.

The other problem with wmi-mof is that there will be no immediate open source
consumers of the interface, and none on the horizon. We can't even test it to
any meaningful degree on Linux. I suspect this will be met with stiff
resistance.

> 
> Also, isn't there a way to ask Microsoft to document this?  Are you
> supposed to "ask a question" on this forum, perhaps:
> 
> https://msdn.microsoft.com/en-us/library/gg134029.aspx
> 
> I'm guessing the Samba team knows how to do this, too.
> 

It's a start.

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-05-08 15:29                                     ` Darren Hart
@ 2017-05-08 15:36                                       ` Mario.Limonciello
  2017-05-08 15:47                                         ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-08 15:36 UTC (permalink / raw)
  To: dvhart, luto
  Cc: pali.rohar, rjw, len.brown, corentin.chary, andriy.shevchenko,
	linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Monday, May 8, 2017 10:29 AM
> To: Andy Lutomirski <luto@kernel.org>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Pali Rohár
> <pali.rohar@gmail.com>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown
> <len.brown@intel.com>; Corentin Chary <corentin.chary@gmail.com>; Andy
> Shevchenko <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 Fri, May 05, 2017 at 06:25:08PM -0700, Andy Lutomirski wrote:
> > On Fri, May 5, 2017 at 5:51 PM,  <Mario.Limonciello@dell.com> wrote:
> > >> -----Original Message-----
> > >> From: Darren Hart [mailto:dvhart@infradead.org]
> > >> Sent: Friday, May 5, 2017 6:45 PM
> > >> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > >> Cc: pali.rohar@gmail.com; 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
> >
> >
> > > I meant that to say that at least for now Andy's wmi-mof driver should still be
> merged.
> > > If something is going to build on top of this to do WBEM tools, they'll need that
> MOF
> > > data once someone figures out how to nicely deconstruct it.
> > >
> >
> > The thing I don't like about my own driver is that, as a WMI device
> > driver, it can be loaded before the rest of the bus finishes probing.
> > So user programs that are notified asynchronously that the wmi-mof
> > driver is loaded and try to use future functionality (ioctl to issue a
> > MOF-based method call?) might end up doing so before the rest of the
> > bus is probed.
> >
> > This could be addressed by always exposing the wmi-mof device last
> > (sort of -- it can be a module) or perhaps by moving MOF functionality
> > to the core driver.  Or maybe it's not really a problem.
> 
> Thanks Andy, I'll keep that in mind and see if I can come up with something to
> address it while working on WMI this week.
> 
> The other problem with wmi-mof is that there will be no immediate open source
> consumers of the interface, and none on the horizon. We can't even test it to
> any meaningful degree on Linux. I suspect this will be met with stiff
> resistance.

Well FWIW I did a quick PoC check with the binary that I got out of it to make 
sure it matched what was supposed to be.  I brought it over to a Win10 box and 
decompiled using the mofcmp tool and those crazy arguments I mentioned and 
it was correct.

I'd argue that even if there is no open source tools available today, not making 
the data available to userspace makes it difficult to even attempt to start 
to reverse engineer.

Kernel config with default of "N" perhaps for wmi-mof?

> 
> >
> > Also, isn't there a way to ask Microsoft to document this?  Are you
> > supposed to "ask a question" on this forum, perhaps:
> >
> > https://msdn.microsoft.com/en-us/library/gg134029.aspx
> >
> > I'm guessing the Samba team knows how to do this, too.
> >

Microsoft treats this as an "intermediary" format.  I'm not convinced
that anyone other than MS knows anything about it today.

I agree asking them to document it is probably the right way to go.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-08 15:36                                       ` Mario.Limonciello
@ 2017-05-08 15:47                                         ` Darren Hart
  2017-05-08 16:00                                           ` Mario.Limonciello
  2017-05-08 16:04                                           ` Andy Shevchenko
  0 siblings, 2 replies; 76+ messages in thread
From: Darren Hart @ 2017-05-08 15:47 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: luto, pali.rohar, rjw, len.brown, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Mon, May 08, 2017 at 03:36:31PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Darren Hart [mailto:dvhart@infradead.org]
> > Sent: Monday, May 8, 2017 10:29 AM
> > To: Andy Lutomirski <luto@kernel.org>
> > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Pali Rohár
> > <pali.rohar@gmail.com>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown
> > <len.brown@intel.com>; Corentin Chary <corentin.chary@gmail.com>; Andy
> > Shevchenko <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 Fri, May 05, 2017 at 06:25:08PM -0700, Andy Lutomirski wrote:
> > > On Fri, May 5, 2017 at 5:51 PM,  <Mario.Limonciello@dell.com> wrote:
> > > >> -----Original Message-----
> > > >> From: Darren Hart [mailto:dvhart@infradead.org]
> > > >> Sent: Friday, May 5, 2017 6:45 PM
> > > >> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > >> Cc: pali.rohar@gmail.com; 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
> > >
> > >
> > > > I meant that to say that at least for now Andy's wmi-mof driver should still be
> > merged.
> > > > If something is going to build on top of this to do WBEM tools, they'll need that
> > MOF
> > > > data once someone figures out how to nicely deconstruct it.
> > > >
> > >
> > > The thing I don't like about my own driver is that, as a WMI device
> > > driver, it can be loaded before the rest of the bus finishes probing.
> > > So user programs that are notified asynchronously that the wmi-mof
> > > driver is loaded and try to use future functionality (ioctl to issue a
> > > MOF-based method call?) might end up doing so before the rest of the
> > > bus is probed.
> > >
> > > This could be addressed by always exposing the wmi-mof device last
> > > (sort of -- it can be a module) or perhaps by moving MOF functionality
> > > to the core driver.  Or maybe it's not really a problem.
> > 
> > Thanks Andy, I'll keep that in mind and see if I can come up with something to
> > address it while working on WMI this week.
> > 
> > The other problem with wmi-mof is that there will be no immediate open source
> > consumers of the interface, and none on the horizon. We can't even test it to
> > any meaningful degree on Linux. I suspect this will be met with stiff
> > resistance.
> 
> Well FWIW I did a quick PoC check with the binary that I got out of it to make 
> sure it matched what was supposed to be.  I brought it over to a Win10 box and 
> decompiled using the mofcmp tool and those crazy arguments I mentioned and 
> it was correct.
> 
> I'd argue that even if there is no open source tools available today, not making 
> the data available to userspace makes it difficult to even attempt to start 
> to reverse engineer.
> 
> Kernel config with default of "N" perhaps for wmi-mof?

All true. There is a precedent we're working against on this. I'll include it in
my leveling-up thread today or tomorrow.

> > 
> > >
> > > Also, isn't there a way to ask Microsoft to document this?  Are you
> > > supposed to "ask a question" on this forum, perhaps:
> > >
> > > https://msdn.microsoft.com/en-us/library/gg134029.aspx
> > >
> > > I'm guessing the Samba team knows how to do this, too.
> > >
> 
> Microsoft treats this as an "intermediary" format.  I'm not convinced
> that anyone other than MS knows anything about it today.
> 
> I agree asking them to document it is probably the right way to go.
> 

Mario, you are most likely in a better position to do that than I am. Would you
take that on?

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-05-08 15:47                                         ` Darren Hart
@ 2017-05-08 16:00                                           ` Mario.Limonciello
  2017-05-08 16:04                                           ` Andy Shevchenko
  1 sibling, 0 replies; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-08 16:00 UTC (permalink / raw)
  To: dvhart
  Cc: luto, pali.rohar, rjw, len.brown, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Monday, May 8, 2017 10:47 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: luto@kernel.org; pali.rohar@gmail.com; rjw@rjwysocki.net;
> len.brown@intel.com; corentin.chary@gmail.com;
> 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 Mon, May 08, 2017 at 03:36:31PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Darren Hart [mailto:dvhart@infradead.org]
> > > Sent: Monday, May 8, 2017 10:29 AM
> > > To: Andy Lutomirski <luto@kernel.org>
> > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Pali Rohár
> > > <pali.rohar@gmail.com>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown
> > > <len.brown@intel.com>; Corentin Chary <corentin.chary@gmail.com>; Andy
> > > Shevchenko <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 Fri, May 05, 2017 at 06:25:08PM -0700, Andy Lutomirski wrote:
> > > > On Fri, May 5, 2017 at 5:51 PM,  <Mario.Limonciello@dell.com> wrote:
> > > > >> -----Original Message-----
> > > > >> From: Darren Hart [mailto:dvhart@infradead.org]
> > > > >> Sent: Friday, May 5, 2017 6:45 PM
> > > > >> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > > >> Cc: pali.rohar@gmail.com; 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
> > > >
> > > >
> > > > > I meant that to say that at least for now Andy's wmi-mof driver should still
> be
> > > merged.
> > > > > If something is going to build on top of this to do WBEM tools, they'll need
> that
> > > MOF
> > > > > data once someone figures out how to nicely deconstruct it.
> > > > >
> > > >
> > > > The thing I don't like about my own driver is that, as a WMI device
> > > > driver, it can be loaded before the rest of the bus finishes probing.
> > > > So user programs that are notified asynchronously that the wmi-mof
> > > > driver is loaded and try to use future functionality (ioctl to issue a
> > > > MOF-based method call?) might end up doing so before the rest of the
> > > > bus is probed.
> > > >
> > > > This could be addressed by always exposing the wmi-mof device last
> > > > (sort of -- it can be a module) or perhaps by moving MOF functionality
> > > > to the core driver.  Or maybe it's not really a problem.
> > >
> > > Thanks Andy, I'll keep that in mind and see if I can come up with something to
> > > address it while working on WMI this week.
> > >
> > > The other problem with wmi-mof is that there will be no immediate open
> source
> > > consumers of the interface, and none on the horizon. We can't even test it to
> > > any meaningful degree on Linux. I suspect this will be met with stiff
> > > resistance.
> >
> > Well FWIW I did a quick PoC check with the binary that I got out of it to make
> > sure it matched what was supposed to be.  I brought it over to a Win10 box and
> > decompiled using the mofcmp tool and those crazy arguments I mentioned and
> > it was correct.
> >
> > I'd argue that even if there is no open source tools available today, not making
> > the data available to userspace makes it difficult to even attempt to start
> > to reverse engineer.
> >
> > Kernel config with default of "N" perhaps for wmi-mof?
> 
> All true. There is a precedent we're working against on this. I'll include it in
> my leveling-up thread today or tomorrow.
> 
> > >
> > > >
> > > > Also, isn't there a way to ask Microsoft to document this?  Are you
> > > > supposed to "ask a question" on this forum, perhaps:
> > > >
> > > > https://msdn.microsoft.com/en-us/library/gg134029.aspx
> > > >
> > > > I'm guessing the Samba team knows how to do this, too.
> > > >
> >
> > Microsoft treats this as an "intermediary" format.  I'm not convinced
> > that anyone other than MS knows anything about it today.
> >
> > I agree asking them to document it is probably the right way to go.
> >
> 
> Mario, you are most likely in a better position to do that than I am. Would you
> take that on?
> 

Sure, I've made a request in that forum here:
https://social.msdn.microsoft.com/Forums/en-US/cc3e50d6-c71d-4ce7-b765-6191f1788697/binary-mof-format?forum=os_specifications

I'll keep you apprise if there is any further details provided by MS.

Thanks,

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-08 15:47                                         ` Darren Hart
  2017-05-08 16:00                                           ` Mario.Limonciello
@ 2017-05-08 16:04                                           ` Andy Shevchenko
       [not found]                                             ` <CAOg5c--wkQgvsmhTynAKyG9iWaHjRWC5Z+MXzVJVw66vxSz4Zw@mail.gmail.com>
  1 sibling, 1 reply; 76+ messages in thread
From: Andy Shevchenko @ 2017-05-08 16:04 UTC (permalink / raw)
  To: Darren Hart, Bokovoy, Alexander
  Cc: Mario Limonciello, Andy Lutomirski, Pali Rohár,
	Rafael J. Wysocki, Brown, Len, Corentin Chary, Andy Shevchenko,
	linux-kernel, Platform Driver, linux-pm

+Cc: Alexander (related to Samba team I suppose, I'm sorry if I'm wrong)

On Mon, May 8, 2017 at 6:47 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Mon, May 08, 2017 at 03:36:31PM +0000, Mario.Limonciello@dell.com wrote:

>> > > > I meant that to say that at least for now Andy's wmi-mof driver should still be
>> > merged.
>> > > > If something is going to build on top of this to do WBEM tools, they'll need that
>> > MOF
>> > > > data once someone figures out how to nicely deconstruct it.
>> > > >
>> > >
>> > > The thing I don't like about my own driver is that, as a WMI device
>> > > driver, it can be loaded before the rest of the bus finishes probing.
>> > > So user programs that are notified asynchronously that the wmi-mof
>> > > driver is loaded and try to use future functionality (ioctl to issue a
>> > > MOF-based method call?) might end up doing so before the rest of the
>> > > bus is probed.
>> > >
>> > > This could be addressed by always exposing the wmi-mof device last
>> > > (sort of -- it can be a module) or perhaps by moving MOF functionality
>> > > to the core driver.  Or maybe it's not really a problem.
>> >
>> > Thanks Andy, I'll keep that in mind and see if I can come up with something to
>> > address it while working on WMI this week.
>> >
>> > The other problem with wmi-mof is that there will be no immediate open source
>> > consumers of the interface, and none on the horizon. We can't even test it to
>> > any meaningful degree on Linux. I suspect this will be met with stiff
>> > resistance.
>>
>> Well FWIW I did a quick PoC check with the binary that I got out of it to make
>> sure it matched what was supposed to be.  I brought it over to a Win10 box and
>> decompiled using the mofcmp tool and those crazy arguments I mentioned and
>> it was correct.
>>
>> I'd argue that even if there is no open source tools available today, not making
>> the data available to userspace makes it difficult to even attempt to start
>> to reverse engineer.
>>
>> Kernel config with default of "N" perhaps for wmi-mof?
>
> All true. There is a precedent we're working against on this. I'll include it in
> my leveling-up thread today or tomorrow.
>
>> >
>> > >
>> > > Also, isn't there a way to ask Microsoft to document this?  Are you
>> > > supposed to "ask a question" on this forum, perhaps:
>> > >
>> > > https://msdn.microsoft.com/en-us/library/gg134029.aspx
>> > >
>> > > I'm guessing the Samba team knows how to do this, too.
>> > >
>>
>> Microsoft treats this as an "intermediary" format.  I'm not convinced
>> that anyone other than MS knows anything about it today.

Alexander, perhaps you would know someone who may help here?

>>
>> I agree asking them to document it is probably the right way to go.
>>
>
> Mario, you are most likely in a better position to do that than I am. Would you
> take that on?


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-05 21:55                             ` Mario.Limonciello
  2017-05-05 23:44                               ` Darren Hart
@ 2017-05-08 17:17                               ` Pali Rohár
  2017-05-08 19:21                                 ` Mario.Limonciello
  1 sibling, 1 reply; 76+ messages in thread
From: Pali Rohár @ 2017-05-08 17:17 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

[-- Attachment #1: Type: Text/Plain, Size: 1355 bytes --]

On Friday 05 May 2017 23:55:46 Mario.Limonciello@dell.com wrote:
> Unfortunately the MOF data that comes out of wmi-mof is so called
> "Binary MOF" which has been pre-compiled to an intermediate format
> with mofcomp.exe on Windows. The format of binary MOF is not
> documented and the only known way to get text mof back out is by
> using mofcomp.exe with some esoteric arguments.
> 
> mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
> binary_mof_file

Looks like that binary MOF file has "well-known" file extension .bmf. 
File itself starts with magic hader "FOMB" which is in reverse BMOF 
(binary mof). But I was not able to find any specification nor any other 
details. As this binary format is dated back to Win9x I guess data would 
compressed by some old MS compression algorithm (CAB?).

Moreover via tool wmiofck.exe it is possible to generate header file for 
WMI driver from binary mof file:

  wmiofck.exe -hfile.h -m -u file.bmf

And what is interesting that in this file are also comments which looks 
like comes from that binary mof file.

When I looked into output from mofcomp.exe with above args, that MOF 
output did not contain comments, so looks like we still can miss 
something.

See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
       [not found]                                             ` <CAOg5c--wkQgvsmhTynAKyG9iWaHjRWC5Z+MXzVJVw66vxSz4Zw@mail.gmail.com>
@ 2017-05-08 18:26                                               ` Mario.Limonciello
  2017-05-08 19:09                                                 ` Darren Hart
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-08 18:26 UTC (permalink / raw)
  To: a.bokovoy, andy.shevchenko
  Cc: dvhart, luto, pali.rohar, rjw, len.brown, corentin.chary,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

(Responding as plain text, your email probably got punted from the ML from being HTML)

>
> ...
>
> I'm not sure what you are asking about. Samba does not deal with WMI at all. The state of affairs is 
> explained at https://powershell.org/2015/04/24/management-information-the-omicimwmimidmtf-dictionary/ 
> -- old WMI (DCOM/RPC-based) is deprecated, new WMI based on WS-MAN is supported and OMI is the 
> implementation. We used to have a very limited attemt at writing DCOM stack and nobody worked on
> it for years so it got removed.

Thanks!  That was a very interesting read.

> Microsoft has already published a MOF parser as part of OMI work: https://github.com/Microsoft/omi/ 
> under MIT license.

Unfortunately that's expecting text MOF, not this intermediary compiled format.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-08 18:26                                               ` Mario.Limonciello
@ 2017-05-08 19:09                                                 ` Darren Hart
  2017-05-08 19:11                                                   ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Darren Hart @ 2017-05-08 19:09 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: a.bokovoy, andy.shevchenko, luto, pali.rohar, rjw, len.brown,
	corentin.chary, andriy.shevchenko, linux-kernel,
	platform-driver-x86, linux-pm

On Mon, May 08, 2017 at 06:26:53PM +0000, Mario.Limonciello@dell.com wrote:
> (Responding as plain text, your email probably got punted from the ML from being HTML)
> 
> >
> > ...
> >
> > I'm not sure what you are asking about. Samba does not deal with WMI at all. The state of affairs is 
> > explained at https://powershell.org/2015/04/24/management-information-the-omicimwmimidmtf-dictionary/ 
> > -- old WMI (DCOM/RPC-based) is deprecated, new WMI based on WS-MAN is supported and OMI is the 
> > implementation. We used to have a very limited attemt at writing DCOM stack and nobody worked on
> > it for years so it got removed.
> 
> Thanks!  That was a very interesting read.
> 
> > Microsoft has already published a MOF parser as part of OMI work: https://github.com/Microsoft/omi/ 
> > under MIT license.
> 
> Unfortunately that's expecting text MOF, not this intermediary compiled format.
> 

I presume which of these to use is the decision of the vendor? Is there a
transition going on from BMOF to Text MOF? Or will both be part of products for
the near term?

I'm trying to understand if BMOF is a legacy thing now, or if it will continue
to be used in new designs.

-- 
Darren Hart
VMware Open Source Technology Center

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-05-08 19:09                                                 ` Darren Hart
@ 2017-05-08 19:11                                                   ` Mario.Limonciello
  0 siblings, 0 replies; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-08 19:11 UTC (permalink / raw)
  To: dvhart
  Cc: a.bokovoy, andy.shevchenko, luto, pali.rohar, rjw, len.brown,
	corentin.chary, andriy.shevchenko, linux-kernel,
	platform-driver-x86, linux-pm

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Monday, May 8, 2017 2:09 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: a.bokovoy@gmail.com; andy.shevchenko@gmail.com; luto@kernel.org;
> pali.rohar@gmail.com; rjw@rjwysocki.net; len.brown@intel.com;
> corentin.chary@gmail.com; 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 Mon, May 08, 2017 at 06:26:53PM +0000, Mario.Limonciello@dell.com wrote:
> > (Responding as plain text, your email probably got punted from the ML from
> being HTML)
> >
> > >
> > > ...
> > >
> > > I'm not sure what you are asking about. Samba does not deal with WMI at all.
> The state of affairs is
> > > explained at https://powershell.org/2015/04/24/management-information-
> the-omicimwmimidmtf-dictionary/
> > > -- old WMI (DCOM/RPC-based) is deprecated, new WMI based on WS-MAN is
> supported and OMI is the
> > > implementation. We used to have a very limited attemt at writing DCOM stack
> and nobody worked on
> > > it for years so it got removed.
> >
> > Thanks!  That was a very interesting read.
> >
> > > Microsoft has already published a MOF parser as part of OMI work:
> https://github.com/Microsoft/omi/
> > > under MIT license.
> >
> > Unfortunately that's expecting text MOF, not this intermediary compiled format.
> >
> 
> I presume which of these to use is the decision of the vendor? 

No, MS documentation indicates to store binary MOF in the ACPI buffer.

>Is there a
> transition going on from BMOF to Text MOF? Or will both be part of products for
> the near term?
> 

Binary MOF will be part of products unless MS or a standards group decides to 
announce something new for OEM's to use in this space.

> I'm trying to understand if BMOF is a legacy thing now, or if it will continue
> to be used in new designs.

Should be continued to use in new designs.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-05-08 17:17                               ` Pali Rohár
@ 2017-05-08 19:21                                 ` Mario.Limonciello
  2017-05-08 20:59                                   ` Pali Rohár
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-08 19:21 UTC (permalink / raw)
  To: pali.rohar
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm



> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, May 8, 2017 12:18 PM
> 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 Friday 05 May 2017 23:55:46 Mario.Limonciello@dell.com wrote:
> > Unfortunately the MOF data that comes out of wmi-mof is so called
> > "Binary MOF" which has been pre-compiled to an intermediate format
> > with mofcomp.exe on Windows. The format of binary MOF is not
> > documented and the only known way to get text mof back out is by
> > using mofcomp.exe with some esoteric arguments.
> >
> > mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
> > binary_mof_file
> 
> Looks like that binary MOF file has "well-known" file extension .bmf.
> File itself starts with magic hader "FOMB" which is in reverse BMOF
> (binary mof). But I was not able to find any specification nor any other
> details. As this binary format is dated back to Win9x I guess data would
> compressed by some old MS compression algorithm (CAB?).

Actually comparing a couple of binary MOF files the first 8 look like the 
header to me.

0x46, 0x4f, 0x4d, 0x42, 0x01, 0x00, 0x00, 0x00

On a compiled Dell binary MOF the next are:

0xed, 0x04, 0x00, 0x00,

This looks like the size of the remaining data after taking out 16 for the headers
4ed = 1261
Total size is 1277

0xd8, 0x15, 0x00, 0x00
Maybe a checksum?

But that first 16 bytes does look like the header structure to me.

> 
> Moreover via tool wmiofck.exe it is possible to generate header file for
> WMI driver from binary mof file:
> 
>   wmiofck.exe -hfile.h -m -u file.bmf
> 
> And what is interesting that in this file are also comments which looks
> like comes from that binary mof file.

Ah interesting.  The "comments" that come out of that are actually what's
mapped to the "Description" field in the WMI repository when the binary
MOF is loaded.  

They are not the developer comments that were placed in the original
MOF data.  I would suppose those are lost when compiling to binary MOF.

> 
> When I looked into output from mofcomp.exe with above args, that MOF
> output did not contain comments, so looks like we still can miss
> something.
> 
> See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html

Actually I see wmimofck output to be missing some important bits.
For example on a Dell system You'll get a class BFn declared from
mofcomp output, but nothing from wmimofck output.

The most important thing that you're really getting out of this MOF is
the size, structure and format of the buffer that you would be sending 
to ASL.

Back to the point we were discussing of a potential filter, the information
in the MOF could possibly be very useful to declaring what is going into the 
filter.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-08 19:21                                 ` Mario.Limonciello
@ 2017-05-08 20:59                                   ` Pali Rohár
  2017-05-08 21:18                                     ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Pali Rohár @ 2017-05-08 20:59 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

[-- Attachment #1: Type: Text/Plain, Size: 4136 bytes --]

On Monday 08 May 2017 21:21:45 Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Monday, May 8, 2017 12:18 PM
> > 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 Friday 05 May 2017 23:55:46 Mario.Limonciello@dell.com wrote:
> > > Unfortunately the MOF data that comes out of wmi-mof is so called
> > > "Binary MOF" which has been pre-compiled to an intermediate
> > > format with mofcomp.exe on Windows. The format of binary MOF is
> > > not documented and the only known way to get text mof back out
> > > is by using mofcomp.exe with some esoteric arguments.
> > > 
> > > mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
> > > binary_mof_file
> > 
> > Looks like that binary MOF file has "well-known" file extension
> > .bmf. File itself starts with magic hader "FOMB" which is in
> > reverse BMOF (binary mof). But I was not able to find any
> > specification nor any other details. As this binary format is
> > dated back to Win9x I guess data would compressed by some old MS
> > compression algorithm (CAB?).
> 
> Actually comparing a couple of binary MOF files the first 8 look like
> the header to me.
> 
> 0x46, 0x4f, 0x4d, 0x42, 0x01, 0x00, 0x00, 0x00
> 
> On a compiled Dell binary MOF the next are:
> 
> 0xed, 0x04, 0x00, 0x00,
> 
> This looks like the size of the remaining data after taking out 16
> for the headers 4ed = 1261
> Total size is 1277
> 
> 0xd8, 0x15, 0x00, 0x00
> Maybe a checksum?
> 
> But that first 16 bytes does look like the header structure to me.

Good catch! Your observation for first 12 bytes passes also for my 
checks.

Next 4 bytes (after possible checksum) at 0x10 are always same:
0x44 0x53 0x00 0x01.

And I guess this should be compression header. In time of Win9x 
Microsoft had own non-standard compression for disks called DoubleSpace. 
IIRC it was some modification of LZ77 algorithm. And 0x44 0x53 0x00 0x01 
is DS01. Maybe it is really DoubleSpace compression used for binary MOF?

I'm going to find specification of that old compression algorithm...

> > Moreover via tool wmiofck.exe it is possible to generate header
> > file for
> > 
> > WMI driver from binary mof file:
> >   wmiofck.exe -hfile.h -m -u file.bmf
> > 
> > And what is interesting that in this file are also comments which
> > looks like comes from that binary mof file.
> 
> Ah interesting.  The "comments" that come out of that are actually
> what's mapped to the "Description" field in the WMI repository when
> the binary MOF is loaded.
> 
> They are not the developer comments that were placed in the original
> MOF data.  I would suppose those are lost when compiling to binary
> MOF.

Hm.. right they are present in decompiled MOF file in Description field.

> > When I looked into output from mofcomp.exe with above args, that
> > MOF output did not contain comments, so looks like we still can
> > miss something.
> > 
> > See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html
> 
> Actually I see wmimofck output to be missing some important bits.
> For example on a Dell system You'll get a class BFn declared from
> mofcomp output, but nothing from wmimofck output.
> 
> The most important thing that you're really getting out of this MOF
> is the size, structure and format of the buffer that you would be
> sending to ASL.
> 
> Back to the point we were discussing of a potential filter, the
> information in the MOF could possibly be very useful to declaring
> what is going into the filter.

In that header file generated by wmiofck.exe I see definitions for BFn. 
And there are also sizes for BFn buffers, together with some types.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-05-08 20:59                                   ` Pali Rohár
@ 2017-05-08 21:18                                     ` Mario.Limonciello
  2017-05-08 22:17                                       ` Pali Rohár
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-08 21:18 UTC (permalink / raw)
  To: pali.rohar
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, May 8, 2017 4:00 PM
> 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 Monday 08 May 2017 21:21:45 Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > Sent: Monday, May 8, 2017 12:18 PM
> > > 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 Friday 05 May 2017 23:55:46 Mario.Limonciello@dell.com wrote:
> > > > Unfortunately the MOF data that comes out of wmi-mof is so called
> > > > "Binary MOF" which has been pre-compiled to an intermediate
> > > > format with mofcomp.exe on Windows. The format of binary MOF is
> > > > not documented and the only known way to get text mof back out
> > > > is by using mofcomp.exe with some esoteric arguments.
> > > >
> > > > mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
> > > > binary_mof_file
> > >
> > > Looks like that binary MOF file has "well-known" file extension
> > > .bmf. File itself starts with magic hader "FOMB" which is in
> > > reverse BMOF (binary mof). But I was not able to find any
> > > specification nor any other details. As this binary format is
> > > dated back to Win9x I guess data would compressed by some old MS
> > > compression algorithm (CAB?).
> >
> > Actually comparing a couple of binary MOF files the first 8 look like
> > the header to me.
> >
> > 0x46, 0x4f, 0x4d, 0x42, 0x01, 0x00, 0x00, 0x00
> >
> > On a compiled Dell binary MOF the next are:
> >
> > 0xed, 0x04, 0x00, 0x00,
> >
> > This looks like the size of the remaining data after taking out 16
> > for the headers 4ed = 1261
> > Total size is 1277
> >
> > 0xd8, 0x15, 0x00, 0x00
> > Maybe a checksum?
> >
> > But that first 16 bytes does look like the header structure to me.
> 
> Good catch! Your observation for first 12 bytes passes also for my
> checks.
> 
> Next 4 bytes (after possible checksum) at 0x10 are always same:
> 0x44 0x53 0x00 0x01.
> 
> And I guess this should be compression header. In time of Win9x
> Microsoft had own non-standard compression for disks called DoubleSpace.
> IIRC it was some modification of LZ77 algorithm. And 0x44 0x53 0x00 0x01
> is DS01. Maybe it is really DoubleSpace compression used for binary MOF?
> 
> I'm going to find specification of that old compression algorithm...
> 
44 53 looks promising to be quantum compression.
https://en.wikipedia.org/wiki/Quantum_compression

That’s also what 'file' magic detects from it too.
$ file mof.stripped 
mof.stripped: Quantum archive data

> > > Moreover via tool wmiofck.exe it is possible to generate header
> > > file for
> > >
> > > WMI driver from binary mof file:
> > >   wmiofck.exe -hfile.h -m -u file.bmf
> > >
> > > And what is interesting that in this file are also comments which
> > > looks like comes from that binary mof file.
> >
> > Ah interesting.  The "comments" that come out of that are actually
> > what's mapped to the "Description" field in the WMI repository when
> > the binary MOF is loaded.
> >
> > They are not the developer comments that were placed in the original
> > MOF data.  I would suppose those are lost when compiling to binary
> > MOF.
> 
> Hm.. right they are present in decompiled MOF file in Description field.
> 
> > > When I looked into output from mofcomp.exe with above args, that
> > > MOF output did not contain comments, so looks like we still can
> > > miss something.
> > >
> > > See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html
> >
> > Actually I see wmimofck output to be missing some important bits.
> > For example on a Dell system You'll get a class BFn declared from
> > mofcomp output, but nothing from wmimofck output.
> >
> > The most important thing that you're really getting out of this MOF
> > is the size, structure and format of the buffer that you would be
> > sending to ASL.
> >
> > Back to the point we were discussing of a potential filter, the
> > information in the MOF could possibly be very useful to declaring
> > what is going into the filter.
> 
> In that header file generated by wmiofck.exe I see definitions for BFn.
There is a definition but it's missing the format of the argument from
what I can tell.

In any case, this will be tangential to this discussion, but useful for
reverse engineering the binary mof format.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-08 21:18                                     ` Mario.Limonciello
@ 2017-05-08 22:17                                       ` Pali Rohár
  2017-05-09  1:10                                         ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Pali Rohár @ 2017-05-08 22:17 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

[-- Attachment #1: Type: Text/Plain, Size: 6131 bytes --]

On Monday 08 May 2017 23:18:11 Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Monday, May 8, 2017 4:00 PM
> > 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 Monday 08 May 2017 21:21:45 Mario.Limonciello@dell.com wrote:
> > > > -----Original Message-----
> > > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > > Sent: Monday, May 8, 2017 12:18 PM
> > > > 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 Friday 05 May 2017 23:55:46 Mario.Limonciello@dell.com wrote:
> > > > > Unfortunately the MOF data that comes out of wmi-mof is so
> > > > > called "Binary MOF" which has been pre-compiled to an
> > > > > intermediate format with mofcomp.exe on Windows. The format
> > > > > of binary MOF is not documented and the only known way to
> > > > > get text mof back out is by using mofcomp.exe with some
> > > > > esoteric arguments.
> > > > > 
> > > > > mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof
> > > > > -Amendment:MS_409 binary_mof_file
> > > > 
> > > > Looks like that binary MOF file has "well-known" file extension
> > > > .bmf. File itself starts with magic hader "FOMB" which is in
> > > > reverse BMOF (binary mof). But I was not able to find any
> > > > specification nor any other details. As this binary format is
> > > > dated back to Win9x I guess data would compressed by some old
> > > > MS compression algorithm (CAB?).
> > > 
> > > Actually comparing a couple of binary MOF files the first 8 look
> > > like the header to me.
> > > 
> > > 0x46, 0x4f, 0x4d, 0x42, 0x01, 0x00, 0x00, 0x00
> > > 
> > > On a compiled Dell binary MOF the next are:
> > > 
> > > 0xed, 0x04, 0x00, 0x00,
> > > 
> > > This looks like the size of the remaining data after taking out
> > > 16 for the headers 4ed = 1261
> > > Total size is 1277
> > > 
> > > 0xd8, 0x15, 0x00, 0x00
> > > Maybe a checksum?
> > > 
> > > But that first 16 bytes does look like the header structure to
> > > me.
> > 
> > Good catch! Your observation for first 12 bytes passes also for my
> > checks.
> > 
> > Next 4 bytes (after possible checksum) at 0x10 are always same:
> > 0x44 0x53 0x00 0x01.
> > 
> > And I guess this should be compression header. In time of Win9x
> > Microsoft had own non-standard compression for disks called
> > DoubleSpace. IIRC it was some modification of LZ77 algorithm. And
> > 0x44 0x53 0x00 0x01 is DS01. Maybe it is really DoubleSpace
> > compression used for binary MOF?
> > 
> > I'm going to find specification of that old compression
> > algorithm...

I found dmsdos implementation of that DS compression at:
http://cmp.felk.cvut.cz/~pisa/dmsdos

Then took relevant decompression code and it really decompressed that 
binary MOF WMI buffer. But still decompressed format is binary, but I 
now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again 
"FOMB" magic header.

I pushed my decompression utility here:
https://github.com/pali/bmfdec

So next step is to decode that decompressed binary MOF file.

> 44 53 looks promising to be quantum compression.
> https://en.wikipedia.org/wiki/Quantum_compression
> 
> That’s also what 'file' magic detects from it too.
> $ file mof.stripped
> mof.stripped: Quantum archive data

Hm... so that Quantum compression is also modification of LZ77. And 
probably it is same as DoubleSpace format (or use it).

> > > > Moreover via tool wmiofck.exe it is possible to generate header
> > > > file for
> > > > 
> > > > WMI driver from binary mof file:
> > > >   wmiofck.exe -hfile.h -m -u file.bmf
> > > > 
> > > > And what is interesting that in this file are also comments
> > > > which looks like comes from that binary mof file.
> > > 
> > > Ah interesting.  The "comments" that come out of that are
> > > actually what's mapped to the "Description" field in the WMI
> > > repository when the binary MOF is loaded.
> > > 
> > > They are not the developer comments that were placed in the
> > > original MOF data.  I would suppose those are lost when
> > > compiling to binary MOF.
> > 
> > Hm.. right they are present in decompiled MOF file in Description
> > field.
> > 
> > > > When I looked into output from mofcomp.exe with above args,
> > > > that MOF output did not contain comments, so looks like we
> > > > still can miss something.
> > > > 
> > > > See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html
> > > 
> > > Actually I see wmimofck output to be missing some important bits.
> > > For example on a Dell system You'll get a class BFn declared from
> > > mofcomp output, but nothing from wmimofck output.
> > > 
> > > The most important thing that you're really getting out of this
> > > MOF is the size, structure and format of the buffer that you
> > > would be sending to ASL.
> > > 
> > > Back to the point we were discussing of a potential filter, the
> > > information in the MOF could possibly be very useful to declaring
> > > what is going into the filter.
> > 
> > In that header file generated by wmiofck.exe I see definitions for
> > BFn.
> 
> There is a definition but it's missing the format of the argument
> from what I can tell.
> 
> In any case, this will be tangential to this discussion, but useful
> for reverse engineering the binary mof format.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-05-08 22:17                                       ` Pali Rohár
@ 2017-05-09  1:10                                         ` Mario.Limonciello
  2017-05-09  7:29                                           ` Pali Rohár
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-09  1:10 UTC (permalink / raw)
  To: pali.rohar
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> 
> I found dmsdos implementation of that DS compression at:
> http://cmp.felk.cvut.cz/~pisa/dmsdos
> 
> Then took relevant decompression code and it really decompressed that
> binary MOF WMI buffer. But still decompressed format is binary, but I
> now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again
> "FOMB" magic header.

Well that's great.  Is it possible that this compression is used for every time
a class was declared?

> 
> I pushed my decompression utility here:
> https://github.com/pali/bmfdec

Did you forget another commit for pulling in arguments and opening a file
or were you just putting the whole buffer into pin?

> 
> So next step is to decode that decompressed binary MOF file.
> 
> > 44 53 looks promising to be quantum compression.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-09  1:10                                         ` Mario.Limonciello
@ 2017-05-09  7:29                                           ` Pali Rohár
  2017-05-09 18:10                                             ` Mario.Limonciello
  0 siblings, 1 reply; 76+ messages in thread
From: Pali Rohár @ 2017-05-09  7:29 UTC (permalink / raw)
  To: Mario.Limonciello
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

On Tuesday 09 May 2017 01:10:54 Mario.Limonciello@dell.com wrote:
> > 
> > I found dmsdos implementation of that DS compression at:
> > http://cmp.felk.cvut.cz/~pisa/dmsdos
> > 
> > Then took relevant decompression code and it really decompressed that
> > binary MOF WMI buffer. But still decompressed format is binary, but I
> > now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again
> > "FOMB" magic header.
> 
> Well that's great.  Is it possible that this compression is used for every time
> a class was declared?

Looks like not. That decompressed output seems to be not compressed
anymore. Just use same magic header.

Now it looks like binary representation of MOF. Where structures and
types are encoded by binary sequences.

> > 
> > I pushed my decompression utility here:
> > https://github.com/pali/bmfdec
> 
> Did you forget another commit for pulling in arguments and opening a file
> or were you just putting the whole buffer into pin?

Whole BMF file should be on stdin (with that 16 bytes header) and is
decompressed on stdout.

> > 
> > So next step is to decode that decompressed binary MOF file.
> > 
> > > 44 53 looks promising to be quantum compression.

So... it is not Quantum compression. BMF content does not pass Quantum
header where is number of files (too huge).

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-05-09  7:29                                           ` Pali Rohár
@ 2017-05-09 18:10                                             ` Mario.Limonciello
  2017-05-09 19:04                                               ` Andy Shevchenko
  0 siblings, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-09 18:10 UTC (permalink / raw)
  To: pali.rohar
  Cc: dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Tuesday, May 9, 2017 2:29 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 Tuesday 09 May 2017 01:10:54 Mario.Limonciello@dell.com wrote:
> > >
> > > I found dmsdos implementation of that DS compression at:
> > > http://cmp.felk.cvut.cz/~pisa/dmsdos
> > >
> > > Then took relevant decompression code and it really decompressed that
> > > binary MOF WMI buffer. But still decompressed format is binary, but I
> > > now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again
> > > "FOMB" magic header.
> >
> > Well that's great.  Is it possible that this compression is used for every time
> > a class was declared?
> 
> Looks like not. That decompressed output seems to be not compressed
> anymore. Just use same magic header.
Actually it looks like a new magic header to me after decompressed.

46 4f 4d 42 54 15 00 00  01 00 00 00 01 00 00 00
That's now FOMBT

> 
> Now it looks like binary representation of MOF. Where structures and
> types are encoded by binary sequences.
Yes, and I notice in here even mentions of the locale (which was required
to decompress using mofcomp too).

00000150  08 00 00 00 00 00 00 00  10 00 00 00 4c 00 6f 00  |............L.o.|
00000160  63 00 61 00 6c 00 65 00  00 00 00 00 4d 00 53 00  |c.a.l.e.....M.S.|
00000170  5c 00 30 00 78 00 34 00  30 00 39 00 00 00 00 00  |\.0.x.4.0.9.....|

> 
> > >
> > > I pushed my decompression utility here:
> > > https://github.com/pali/bmfdec
> >
> > Did you forget another commit for pulling in arguments and opening a file
> > or were you just putting the whole buffer into pin?
> 
> Whole BMF file should be on stdin (with that 16 bytes header) and is
> decompressed on stdout.
Oh my mistake, that wasn't clear when I glanced at it.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-09 18:10                                             ` Mario.Limonciello
@ 2017-05-09 19:04                                               ` Andy Shevchenko
  2017-05-09 19:16                                                 ` Mario.Limonciello
  2017-05-09 19:19                                                 ` Pali Rohár
  0 siblings, 2 replies; 76+ messages in thread
From: Andy Shevchenko @ 2017-05-09 19:04 UTC (permalink / raw)
  To: Mario Limonciello
  Cc: Pali Rohár, dvhart, Rafael J. Wysocki, Andy Lutomirski,
	Brown, Len, Corentin Chary, Andy Lutomirski, Andy Shevchenko,
	linux-kernel, Platform Driver, linux-pm

On Tue, May 9, 2017 at 9:10 PM,  <Mario.Limonciello@dell.com> wrote:

>> > > Then took relevant decompression code and it really decompressed that
>> > > binary MOF WMI buffer. But still decompressed format is binary, but I
>> > > now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again
>> > > "FOMB" magic header.
>> >
>> > Well that's great.  Is it possible that this compression is used for every time
>> > a class was declared?
>>
>> Looks like not. That decompressed output seems to be not compressed
>> anymore. Just use same magic header.
> Actually it looks like a new magic header to me after decompressed.
>
> 46 4f 4d 42 54 15 00 00  01 00 00 00 01 00 00 00
> That's now FOMBT

I think you just mistakenly take 0x54 as letter when it looks more like

0x00001554
0x00000001
0x00000001

from the above dump.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 76+ messages in thread

* RE: RFC: WMI Enhancements
  2017-05-09 19:04                                               ` Andy Shevchenko
@ 2017-05-09 19:16                                                 ` Mario.Limonciello
  2017-05-09 19:26                                                   ` Andy Shevchenko
  2017-05-09 19:19                                                 ` Pali Rohár
  1 sibling, 1 reply; 76+ messages in thread
From: Mario.Limonciello @ 2017-05-09 19:16 UTC (permalink / raw)
  To: andy.shevchenko
  Cc: pali.rohar, dvhart, rjw, luto, len.brown, corentin.chary, luto,
	andriy.shevchenko, linux-kernel, platform-driver-x86, linux-pm

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Tuesday, May 9, 2017 2:04 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: Pali Rohár <pali.rohar@gmail.com>; dvhart@infradead.org; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Andy Lutomirski <luto@amacapital.net>; Brown, Len
> <len.brown@intel.com>; Corentin Chary <corentin.chary@gmail.com>; Andy
> Lutomirski <luto@kernel.org>; Andy Shevchenko
> <andriy.shevchenko@linux.intel.com>; linux-kernel@vger.kernel.org; Platform
> Driver <platform-driver-x86@vger.kernel.org>; linux-pm@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Tue, May 9, 2017 at 9:10 PM,  <Mario.Limonciello@dell.com> wrote:
> 
> >> > > Then took relevant decompression code and it really decompressed that
> >> > > binary MOF WMI buffer. But still decompressed format is binary, but I
> >> > > now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again
> >> > > "FOMB" magic header.
> >> >
> >> > Well that's great.  Is it possible that this compression is used for every time
> >> > a class was declared?
> >>
> >> Looks like not. That decompressed output seems to be not compressed
> >> anymore. Just use same magic header.
> > Actually it looks like a new magic header to me after decompressed.
> >
> > 46 4f 4d 42 54 15 00 00  01 00 00 00 01 00 00 00
> > That's now FOMBT
> 
> I think you just mistakenly take 0x54 as letter when it looks more like
> 
> 0x00001554
> 0x00000001
> 0x00000001
> 
> from the above dump.
Ah, that's true, but second word is different than original was main point.
We didn't know what that represented (maybe it's part of magic header).

46 4f 4d 42 01 00 00 00  ed 04 00 00 d8 15 00 00
0x00000001

> --
> With Best Regards,
> Andy Shevchenko

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-09 19:04                                               ` Andy Shevchenko
  2017-05-09 19:16                                                 ` Mario.Limonciello
@ 2017-05-09 19:19                                                 ` Pali Rohár
  1 sibling, 0 replies; 76+ messages in thread
From: Pali Rohár @ 2017-05-09 19:19 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Mario Limonciello, dvhart, Rafael J. Wysocki, Andy Lutomirski,
	Brown, Len, Corentin Chary, Andy Lutomirski, Andy Shevchenko,
	linux-kernel, Platform Driver, linux-pm

[-- Attachment #1: Type: Text/Plain, Size: 1377 bytes --]

On Tuesday 09 May 2017 21:04:15 Andy Shevchenko wrote:
> On Tue, May 9, 2017 at 9:10 PM,  <Mario.Limonciello@dell.com> wrote:
> >> > > Then took relevant decompression code and it really
> >> > > decompressed that binary MOF WMI buffer. But still
> >> > > decompressed format is binary, but I now see all WMI GUID
> >> > > encoded in UTF-16. Decompressed BMF file has again "FOMB"
> >> > > magic header.
> >> > 
> >> > Well that's great.  Is it possible that this compression is used
> >> > for every time a class was declared?
> >> 
> >> Looks like not. That decompressed output seems to be not
> >> compressed anymore. Just use same magic header.
> > 
> > Actually it looks like a new magic header to me after decompressed.
> > 
> > 46 4f 4d 42 54 15 00 00  01 00 00 00 01 00 00 00
> > That's now FOMBT
> 
> I think you just mistakenly take 0x54 as letter when it looks more
> like
> 
> 0x00001554
> 0x00000001
> 0x00000001
> 
> from the above dump.

I looked at more decompressed BMF dumps from ACPI WMI and they have 
different 5th and 6th bytes. So they are really not FOMBT.

46 4f 4d 42 26 35 00 00 01 00 00 00 01 00 00 00
46 4f 4d 42 fa 17 00 00 01 00 00 00 01 00 00 00
46 4f 4d 42 8e 11 00 00 01 00 00 00 01 00 00 00
46 4f 4d 42 ac 1b 00 00 01 00 00 00 01 00 00 00

So magic is only FOMB.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-09 19:16                                                 ` Mario.Limonciello
@ 2017-05-09 19:26                                                   ` Andy Shevchenko
  2017-05-09 22:38                                                     ` Pali Rohár
  0 siblings, 1 reply; 76+ messages in thread
From: Andy Shevchenko @ 2017-05-09 19:26 UTC (permalink / raw)
  To: Mario Limonciello
  Cc: Pali Rohár, dvhart, Rafael J. Wysocki, Andy Lutomirski,
	Brown, Len, Corentin Chary, Andy Lutomirski, Andy Shevchenko,
	linux-kernel, Platform Driver, linux-pm

On Tue, May 9, 2017 at 10:16 PM,  <Mario.Limonciello@dell.com> wrote:


>> > 46 4f 4d 42 54 15 00 00  01 00 00 00 01 00 00 00
>> > That's now FOMBT
>>
>> I think you just mistakenly take 0x54 as letter when it looks more like
>>

>> 0x00001554

This one looks like offset (or size 5460)

>> 0x00000001
>> 0x00000001
>>
>> from the above dump.
> Ah, that's true, but second word is different than original was main point.
> We didn't know what that represented (maybe it's part of magic header).
>

> 46 4f 4d 42 01 00 00 00  ed 04 00 00 d8 15 00 00
> 0x00000001

0x000015d8

Again, looks like offset (or size).

0x000004ed



-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: RFC: WMI Enhancements
  2017-05-09 19:26                                                   ` Andy Shevchenko
@ 2017-05-09 22:38                                                     ` Pali Rohár
  0 siblings, 0 replies; 76+ messages in thread
From: Pali Rohár @ 2017-05-09 22:38 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Mario Limonciello, dvhart, Rafael J. Wysocki, Andy Lutomirski,
	Brown, Len, Corentin Chary, Andy Lutomirski, Andy Shevchenko,
	linux-kernel, Platform Driver, linux-pm

[-- Attachment #1: Type: Text/Plain, Size: 1283 bytes --]

I updated my bmfdec.c (git://github.com/pali/bmfdec.git) and here is
guessed header description:

/*
 * BMF file is compressed by DS-01 algorithm with additional header:
 * 4 bytes: 46 4f 4d 42 - 'F' 'O' 'M' 'B'
 * 4 bytes: 01 00 00 00 - version 0x01
 * 4 bytes: size of compressed data (low endian) without this header
 * 4 bytes: size of decompressed data (low endian) without this header
 */

/*
 * Decompressed part of BMF file contains:
 * 4 bytes: 46 4f 4d 42 - 'F' 'O' 'M' 'B'
 * 4 bytes: N = size of first part (low endian) since beginning
 * N-8 bytes: first part data
 * 16 bytes: 42 4d 4f 46 51 55 41 4c 46 4c 41 56 4f 52 31 31 - "BMOFQUALFLAVOR11"
 * M bytes: second part data of unknown length
 */

First part of decompressed data contains UTF-16 strings terminated by
two zero bytes and between two strings are some binary data. Those
strings are just literals found in decompiled MOF file, so looks like
binary parts just decodes types and MOF language keywords.

And it looks like second part is not required and sometimes missing.
It contains only binary data, no idea what is there.

Now somebody with knowledge of MOF language should be able to describe
what and how is stored in first part.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 76+ messages in thread

end of thread, other threads:[~2017-05-09 22:38 UTC | newest]

Thread overview: 76+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-12 23:08 RFC: WMI Enhancements Darren Hart
2017-04-13  7:32 ` Michał Kępień
2017-04-13 13:29   ` Mario.Limonciello
2017-04-13 13:51     ` Pali Rohár
2017-04-13 15:34       ` Andy Lutomirski
2017-04-13 15:40         ` Mario.Limonciello
2017-04-13 16:06           ` Darren Hart
2017-04-13 15:40       ` Mario.Limonciello
2017-04-18  7:36         ` Andy Shevchenko
2017-04-18 14:08           ` Mario.Limonciello
2017-04-13 15:32   ` Andy Lutomirski
2017-04-13 15:39     ` Pali Rohár
2017-04-13 15:44       ` Andy Lutomirski
2017-04-13 16:09         ` Darren Hart
2017-04-13 15:55     ` Mario.Limonciello
2017-04-13 15:57       ` Andy Lutomirski
2017-04-13 16:54         ` Mario.Limonciello
2017-04-13 17:06           ` Darren Hart
2017-04-13 17:39             ` Mario.Limonciello
2017-04-13 17:44               ` Andy Lutomirski
2017-04-13 17:49                 ` Mario.Limonciello
2017-04-18  7:54               ` Pali Rohár
2017-04-18 16:56                 ` Darren Hart
2017-04-18 19:28                   ` Pali Rohár
2017-04-13 17:02       ` Darren Hart
2017-04-13 17:32         ` Andy Lutomirski
2017-04-13 17:45           ` Mario.Limonciello
2017-04-13 16:08     ` Darren Hart
2017-04-13  7:33 ` Pali Rohár
2017-04-13 16:56   ` Darren Hart
2017-04-13 20:38     ` Mario.Limonciello
2017-04-13 23:51       ` Darren Hart
2017-04-14 17:42         ` Mario.Limonciello
2017-04-14 18:27           ` Darren Hart
2017-04-14 19:04             ` Mario.Limonciello
2017-04-14 22:45 ` Rafael J. Wysocki
2017-04-14 23:05   ` Darren Hart
2017-04-17 22:03     ` Andy Lutomirski
2017-04-17 23:10       ` Darren Hart
2017-04-18 13:07         ` Rafael J. Wysocki
2017-04-18 16:33           ` Darren Hart
2017-04-18 19:28             ` Pali Rohár
2017-04-18 22:49               ` Darren Hart
2017-04-19  7:52                 ` Pali Rohár
2017-04-19 16:29                   ` Mario.Limonciello
2017-04-19 16:54                     ` Pali Rohár
2017-04-19 17:24                       ` Mario.Limonciello
2017-04-20 13:14                         ` Pali Rohár
2017-04-20 20:44                           ` Darren Hart
2017-05-05 21:55                             ` Mario.Limonciello
2017-05-05 23:44                               ` Darren Hart
2017-05-06  0:51                                 ` Mario.Limonciello
2017-05-06  1:25                                   ` Andy Lutomirski
2017-05-08 15:29                                     ` Darren Hart
2017-05-08 15:36                                       ` Mario.Limonciello
2017-05-08 15:47                                         ` Darren Hart
2017-05-08 16:00                                           ` Mario.Limonciello
2017-05-08 16:04                                           ` Andy Shevchenko
     [not found]                                             ` <CAOg5c--wkQgvsmhTynAKyG9iWaHjRWC5Z+MXzVJVw66vxSz4Zw@mail.gmail.com>
2017-05-08 18:26                                               ` Mario.Limonciello
2017-05-08 19:09                                                 ` Darren Hart
2017-05-08 19:11                                                   ` Mario.Limonciello
2017-05-08 17:17                               ` Pali Rohár
2017-05-08 19:21                                 ` Mario.Limonciello
2017-05-08 20:59                                   ` Pali Rohár
2017-05-08 21:18                                     ` Mario.Limonciello
2017-05-08 22:17                                       ` Pali Rohár
2017-05-09  1:10                                         ` Mario.Limonciello
2017-05-09  7:29                                           ` Pali Rohár
2017-05-09 18:10                                             ` Mario.Limonciello
2017-05-09 19:04                                               ` Andy Shevchenko
2017-05-09 19:16                                                 ` Mario.Limonciello
2017-05-09 19:26                                                   ` Andy Shevchenko
2017-05-09 22:38                                                     ` Pali Rohár
2017-05-09 19:19                                                 ` Pali Rohár
2017-04-20 14:17                       ` Christoph Hellwig
2017-04-18 21:14             ` Rafael J. Wysocki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).