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/[email protected]/msg11686.html
--
Darren Hart
VMware Open Source Technology Center
> 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ń
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
[email protected]
> -----Original Message-----
> From: Michał Kępień [mailto:[email protected]]
> Sent: Thursday, April 13, 2017 2:32 AM
> To: Darren Hart <[email protected]>
> Cc: Rafael Wysocki <[email protected]>; Len Brown <[email protected]>;
> Pali Rohár <[email protected]>; Corentin Chary
> <[email protected]>; Limonciello, Mario
> <[email protected]>; Andy Lutomirski <[email protected]>; Andy
> Shevchenko <[email protected]>; LKML <linux-
> [email protected]>; [email protected]; linux-
> [email protected]
> 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ń
On Thursday 13 April 2017 13:29:41 [email protected] 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
[email protected]
On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]> 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.
On Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <[email protected]> wrote:
> On Thursday 13 April 2017 13:29:41 [email protected] 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.
On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]>
> 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
[email protected]
> -----Original Message-----
> From: Pali Rohár [mailto:[email protected]]
> Sent: Thursday, April 13, 2017 8:51 AM
> To: Limonciello, Mario <[email protected]>; Hans de Goede
> <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; platform-
> [email protected]; [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Thursday 13 April 2017 13:29:41 [email protected] 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
> [email protected]
On Thu, Apr 13, 2017 at 8:39 AM, Pali Rohár <[email protected]> wrote:
> On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
>> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]>
>> 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.
> -----Original Message-----
> From: Andy Lutomirski [mailto:[email protected]]
> Sent: Thursday, April 13, 2017 10:35 AM
> To: Pali Rohár <[email protected]>
> Cc: Limonciello, Mario <[email protected]>; Hans de Goede
> <[email protected]>; Michał Kępień <[email protected]>; Darren Hart
> <[email protected]>; Rafael J. Wysocki <[email protected]>; Len Brown
> <[email protected]>; [email protected]; Andrew Lutomirski
> <[email protected]>; Andy Shevchenko <[email protected]>;
> [email protected]; [email protected]; linux-
> [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <[email protected]> wrote:
> > On Thursday 13 April 2017 13:29:41 [email protected] 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.
> -----Original Message-----
> From: Andy Lutomirski [mailto:[email protected]]
> Sent: Thursday, April 13, 2017 10:33 AM
> To: Michał Kępień <[email protected]>
> Cc: Darren Hart <[email protected]>; Rafael Wysocki <[email protected]>;
> Len Brown <[email protected]>; Pali Rohár <[email protected]>; Corentin
> Chary <[email protected]>; Limonciello, Mario
> <[email protected]>; Andy Lutomirski <[email protected]>; Andy
> Shevchenko <[email protected]>; LKML <linux-
> [email protected]>; [email protected]; linux-
> [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]> 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.
On Thu, Apr 13, 2017 at 8:55 AM, <[email protected]> wrote:
>
>
>> -----Original Message-----
>> From: Andy Lutomirski [mailto:[email protected]]
>> Sent: Thursday, April 13, 2017 10:33 AM
>> To: Michał Kępień <[email protected]>
>> Cc: Darren Hart <[email protected]>; Rafael Wysocki <[email protected]>;
>> Len Brown <[email protected]>; Pali Rohár <[email protected]>; Corentin
>> Chary <[email protected]>; Limonciello, Mario
>> <[email protected]>; Andy Lutomirski <[email protected]>; Andy
>> Shevchenko <[email protected]>; LKML <linux-
>> [email protected]>; [email protected]; linux-
>> [email protected]
>> Subject: Re: RFC: WMI Enhancements
>>
>> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]> 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.
On Thu, Apr 13, 2017 at 03:40:08PM +0000, [email protected] wrote:
> > -----Original Message-----
> > From: Andy Lutomirski [mailto:[email protected]]
> > Sent: Thursday, April 13, 2017 10:35 AM
> > To: Pali Rohár <[email protected]>
> > Cc: Limonciello, Mario <[email protected]>; Hans de Goede
> > <[email protected]>; Michał Kępień <[email protected]>; Darren Hart
> > <[email protected]>; Rafael J. Wysocki <[email protected]>; Len Brown
> > <[email protected]>; [email protected]; Andrew Lutomirski
> > <[email protected]>; Andy Shevchenko <[email protected]>;
> > [email protected]; [email protected]; linux-
> > [email protected]
> > Subject: Re: RFC: WMI Enhancements
> >
> > On Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <[email protected]> wrote:
> > > On Thursday 13 April 2017 13:29:41 [email protected] 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
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ń <[email protected]> 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
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 <[email protected]> wrote:
> > On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
> >> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]>
> >> 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
> -----Original Message-----
> From: Andy Lutomirski [mailto:[email protected]]
> Sent: Thursday, April 13, 2017 10:58 AM
> To: Limonciello, Mario <[email protected]>
> Cc: Andrew Lutomirski <[email protected]>; Michał Kępień <[email protected]>;
> Darren Hart <[email protected]>; Rafael J. Wysocki <[email protected]>; Len
> Brown <[email protected]>; Pali Rohár <[email protected]>; Corentin
> Chary <[email protected]>; Andy Shevchenko
> <[email protected]>; [email protected]; platform-
> [email protected]; [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Thu, Apr 13, 2017 at 8:55 AM, <[email protected]> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Andy Lutomirski [mailto:[email protected]]
> >> Sent: Thursday, April 13, 2017 10:33 AM
> >> To: Michał Kępień <[email protected]>
> >> Cc: Darren Hart <[email protected]>; Rafael Wysocki <[email protected]>;
> >> Len Brown <[email protected]>; Pali Rohár <[email protected]>;
> Corentin
> >> Chary <[email protected]>; Limonciello, Mario
> >> <[email protected]>; Andy Lutomirski <[email protected]>; Andy
> >> Shevchenko <[email protected]>; LKML <linux-
> >> [email protected]>; [email protected]; linux-
> >> [email protected]
> >> Subject: Re: RFC: WMI Enhancements
> >>
> >> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]> 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.
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
On Thu, Apr 13, 2017 at 03:55:01PM +0000, [email protected] wrote:
>
>
> > -----Original Message-----
> > From: Andy Lutomirski [mailto:[email protected]]
> > Sent: Thursday, April 13, 2017 10:33 AM
> > To: Michał Kępień <[email protected]>
> > Cc: Darren Hart <[email protected]>; Rafael Wysocki <[email protected]>;
> > Len Brown <[email protected]>; Pali Rohár <[email protected]>; Corentin
> > Chary <[email protected]>; Limonciello, Mario
> > <[email protected]>; Andy Lutomirski <[email protected]>; Andy
> > Shevchenko <[email protected]>; LKML <linux-
> > [email protected]>; [email protected]; linux-
> > [email protected]
> > Subject: Re: RFC: WMI Enhancements
> >
> > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]> 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
On Thu, Apr 13, 2017 at 04:54:25PM +0000, [email protected] wrote:
> > -----Original Message-----
> > From: Andy Lutomirski [mailto:[email protected]]
> > Sent: Thursday, April 13, 2017 10:58 AM
> > To: Limonciello, Mario <[email protected]>
> > Cc: Andrew Lutomirski <[email protected]>; Michał Kępień <[email protected]>;
> > Darren Hart <[email protected]>; Rafael J. Wysocki <[email protected]>; Len
> > Brown <[email protected]>; Pali Rohár <[email protected]>; Corentin
> > Chary <[email protected]>; Andy Shevchenko
> > <[email protected]>; [email protected]; platform-
> > [email protected]; [email protected]
> > Subject: Re: RFC: WMI Enhancements
> >
> > On Thu, Apr 13, 2017 at 8:55 AM, <[email protected]> wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Andy Lutomirski [mailto:[email protected]]
> > >> Sent: Thursday, April 13, 2017 10:33 AM
> > >> To: Michał Kępień <[email protected]>
> > >> Cc: Darren Hart <[email protected]>; Rafael Wysocki <[email protected]>;
> > >> Len Brown <[email protected]>; Pali Rohár <[email protected]>;
> > Corentin
> > >> Chary <[email protected]>; Limonciello, Mario
> > >> <[email protected]>; Andy Lutomirski <[email protected]>; Andy
> > >> Shevchenko <[email protected]>; LKML <linux-
> > >> [email protected]>; [email protected]; linux-
> > >> [email protected]
> > >> Subject: Re: RFC: WMI Enhancements
> > >>
> > >> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]> 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
On Thu, Apr 13, 2017 at 10:02 AM, Darren Hart <[email protected]> wrote:
> On Thu, Apr 13, 2017 at 03:55:01PM +0000, [email protected] wrote:
>>
>>
>> > -----Original Message-----
>> > From: Andy Lutomirski [mailto:[email protected]]
>> > Sent: Thursday, April 13, 2017 10:33 AM
>> > To: Michał Kępień <[email protected]>
>> > Cc: Darren Hart <[email protected]>; Rafael Wysocki <[email protected]>;
>> > Len Brown <[email protected]>; Pali Rohár <[email protected]>; Corentin
>> > Chary <[email protected]>; Limonciello, Mario
>> > <[email protected]>; Andy Lutomirski <[email protected]>; Andy
>> > Shevchenko <[email protected]>; LKML <linux-
>> > [email protected]>; [email protected]; linux-
>> > [email protected]
>> > Subject: Re: RFC: WMI Enhancements
>> >
>> > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]> 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
> -----Original Message-----
> From: Darren Hart [mailto:[email protected]]
> Sent: Thursday, April 13, 2017 12:06 PM
> To: Limonciello, Mario <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; platform-
> [email protected]; [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Thu, Apr 13, 2017 at 04:54:25PM +0000, [email protected] wrote:
> > > -----Original Message-----
> > > From: Andy Lutomirski [mailto:[email protected]]
> > > Sent: Thursday, April 13, 2017 10:58 AM
> > > To: Limonciello, Mario <[email protected]>
> > > Cc: Andrew Lutomirski <[email protected]>; Michał Kępień
> <[email protected]>;
> > > Darren Hart <[email protected]>; Rafael J. Wysocki <[email protected]>;
> Len
> > > Brown <[email protected]>; Pali Rohár <[email protected]>; Corentin
> > > Chary <[email protected]>; Andy Shevchenko
> > > <[email protected]>; [email protected]; platform-
> > > [email protected]; [email protected]
> > > Subject: Re: RFC: WMI Enhancements
> > >
> > > On Thu, Apr 13, 2017 at 8:55 AM, <[email protected]> wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Andy Lutomirski [mailto:[email protected]]
> > > >> Sent: Thursday, April 13, 2017 10:33 AM
> > > >> To: Michał Kępień <[email protected]>
> > > >> Cc: Darren Hart <[email protected]>; Rafael Wysocki
> <[email protected]>;
> > > >> Len Brown <[email protected]>; Pali Rohár <[email protected]>;
> > > Corentin
> > > >> Chary <[email protected]>; Limonciello, Mario
> > > >> <[email protected]>; Andy Lutomirski <[email protected]>; Andy
> > > >> Shevchenko <[email protected]>; LKML <linux-
> > > >> [email protected]>; [email protected]; linux-
> > > >> [email protected]
> > > >> Subject: Re: RFC: WMI Enhancements
> > > >>
> > > >> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]>
> 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.
On Thu, Apr 13, 2017 at 10:39 AM, <[email protected]> wrote:
>> -----Original Message-----
>> From: Darren Hart [mailto:[email protected]]
>> Sent: Thursday, April 13, 2017 12:06 PM
>> To: Limonciello, Mario <[email protected]>
>> Cc: [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; platform-
>> [email protected]; [email protected]
>> 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 :)
> -----Original Message-----
> From: Andy Lutomirski [mailto:[email protected]]
> Sent: Thursday, April 13, 2017 12:33 PM
> To: Darren Hart <[email protected]>
> Cc: Limonciello, Mario <[email protected]>; Andrew Lutomirski
> <[email protected]>; Michał Kępień <[email protected]>; Rafael J. Wysocki
> <[email protected]>; Len Brown <[email protected]>; Pali Rohár
> <[email protected]>; Corentin Chary <[email protected]>; Andy
> Shevchenko <[email protected]>; [email protected];
> [email protected]; [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Thu, Apr 13, 2017 at 10:02 AM, Darren Hart <[email protected]> wrote:
> > On Thu, Apr 13, 2017 at 03:55:01PM +0000, [email protected] wrote:
> >>
> >>
> >> > -----Original Message-----
> >> > From: Andy Lutomirski [mailto:[email protected]]
> >> > Sent: Thursday, April 13, 2017 10:33 AM
> >> > To: Michał Kępień <[email protected]>
> >> > Cc: Darren Hart <[email protected]>; Rafael Wysocki
> <[email protected]>;
> >> > Len Brown <[email protected]>; Pali Rohár <[email protected]>;
> Corentin
> >> > Chary <[email protected]>; Limonciello, Mario
> >> > <[email protected]>; Andy Lutomirski <[email protected]>; Andy
> >> > Shevchenko <[email protected]>; LKML <linux-
> >> > [email protected]>; [email protected]; linux-
> >> > [email protected]
> >> > Subject: Re: RFC: WMI Enhancements
> >> >
> >> > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]>
> 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
> -----Original Message-----
> From: Andy Lutomirski [mailto:[email protected]]
> Sent: Thursday, April 13, 2017 12:44 PM
> To: Limonciello, Mario <[email protected]>
> Cc: Darren Hart <[email protected]>; Andrew Lutomirski <[email protected]>;
> Michał Kępień <[email protected]>; Rafael J. Wysocki <[email protected]>; Len
> Brown <[email protected]>; Pali Rohár <[email protected]>; Corentin
> Chary <[email protected]>; Andy Shevchenko
> <[email protected]>; [email protected]; platform-
> [email protected]; [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Thu, Apr 13, 2017 at 10:39 AM, <[email protected]> wrote:
> >> -----Original Message-----
> >> From: Darren Hart [mailto:[email protected]]
> >> Sent: Thursday, April 13, 2017 12:06 PM
> >> To: Limonciello, Mario <[email protected]>
> >> Cc: [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; platform-
> >> [email protected]; [email protected]
> >> 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.
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.
On Thu, Apr 13, 2017 at 08:38:28PM +0000, [email protected] 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
> -----Original Message-----
> From: Darren Hart [mailto:[email protected]]
> Sent: Thursday, April 13, 2017 6:51 PM
> To: Limonciello, Mario <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Thu, Apr 13, 2017 at 08:38:28PM +0000, [email protected] 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.
On Fri, Apr 14, 2017 at 05:42:03PM +0000, [email protected] wrote:
>
>
> > -----Original Message-----
> > From: Darren Hart [mailto:[email protected]]
> > Sent: Thursday, April 13, 2017 6:51 PM
> > To: Limonciello, Mario <[email protected]>
> > Cc: [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; linux-
> > [email protected]
> > Subject: Re: RFC: WMI Enhancements
> >
> > On Thu, Apr 13, 2017 at 08:38:28PM +0000, [email protected] 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
> -----Original Message-----
> From: Darren Hart [mailto:[email protected]]
> Sent: Friday, April 14, 2017 1:28 PM
> To: Limonciello, Mario <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Fri, Apr 14, 2017 at 05:42:03PM +0000, [email protected] wrote:
> >
> >
> > > -----Original Message-----
> > > From: Darren Hart [mailto:[email protected]]
> > > Sent: Thursday, April 13, 2017 6:51 PM
> > > To: Limonciello, Mario <[email protected]>
> > > Cc: [email protected]; [email protected]; [email protected];
> > > [email protected]; [email protected];
> [email protected];
> > > [email protected]; [email protected]; linux-
> > > [email protected]
> > > Subject: Re: RFC: WMI Enhancements
> > >
> > > On Thu, Apr 13, 2017 at 08:38:28PM +0000, [email protected]
> 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.
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
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
On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart <[email protected]> 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.
On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart <[email protected]> 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
On Thursday 13 April 2017 17:39:56 [email protected] 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
[email protected]
On Thu, 2017-04-13 at 15:40 +0000, [email protected] 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 <[email protected]>
Intel Finland Oy
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 <[email protected]> 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
> -----Original Message-----
> From: Andy Shevchenko [mailto:[email protected]]
> Sent: Tuesday, April 18, 2017 2:37 AM
> To: Limonciello, Mario <[email protected]>; [email protected];
> [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; linux-
> [email protected]; [email protected]; linux-
> [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Thu, 2017-04-13 at 15:40 +0000, [email protected] 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.
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 <[email protected]> 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
On Tue, Apr 18, 2017 at 09:54:01AM +0200, Pali Roh?r wrote:
> On Thursday 13 April 2017 17:39:56 [email protected] 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
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 [email protected] 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
[email protected]
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
> > > > <[email protected]> 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
[email protected]
On Tue, Apr 18, 2017 at 6:33 PM, Darren Hart <[email protected]> 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 <[email protected]> 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
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
> > > > > <[email protected]> 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
> [email protected]
--
Darren Hart
VMware Open Source Technology Center
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
[email protected]
> -----Original Message-----
> From: Pali Rohár [mailto:[email protected]]
> Sent: Wednesday, April 19, 2017 2:53 AM
> To: Darren Hart <[email protected]>
> Cc: Rafael J. Wysocki <[email protected]>; Andy Lutomirski
> <[email protected]>; Len Brown <[email protected]>; Corentin Chary
> <[email protected]>; Limonciello, Mario <[email protected]>;
> Andy Lutomirski <[email protected]>; Andy Shevchenko
> <[email protected]>; LKML <[email protected]>;
> [email protected]; [email protected]
> 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.
On Wednesday 19 April 2017 18:29:53 [email protected] 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
[email protected]
> -----Original Message-----
> From: Pali Rohár [mailto:[email protected]]
> Sent: Wednesday, April 19, 2017 11:55 AM
> To: Limonciello, Mario <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; platform-
> [email protected]; [email protected]
> Subject: Re: RFC: WMI Enhancements
>
> On Wednesday 19 April 2017 18:29:53 [email protected] 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).
On Wednesday 19 April 2017 17:24:00 [email protected] wrote:
> > -----Original Message-----
> > From: Pali Rohár [mailto:[email protected]]
> > Sent: Wednesday, April 19, 2017 11:55 AM
> > To: Limonciello, Mario <[email protected]>
> > Cc: [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; platform-
> > [email protected]; [email protected]
> > Subject: Re: RFC: WMI Enhancements
> >
> > On Wednesday 19 April 2017 18:29:53 [email protected] 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
[email protected]
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.
On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Roh?r wrote:
> On Wednesday 19 April 2017 17:24:00 [email protected] wrote:
> > > -----Original Message-----
> > > From: Pali Roh?r [mailto:[email protected]]
> > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > To: Limonciello, Mario <[email protected]>
> > > Cc: [email protected]; [email protected]; [email protected];
> > > [email protected]; [email protected]; [email protected];
> > > [email protected]; [email protected]; platform-
> > > [email protected]; [email protected]
> > > Subject: Re: RFC: WMI Enhancements
> > >
> > > On Wednesday 19 April 2017 18:29:53 [email protected] 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
> [email protected]
>
--
Darren Hart
VMware Open Source Technology Center