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?
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
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 7 lines
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.
Quoted 8 lines
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.
Quoted 19 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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
Signature · 2 lines
Best regards, Michał Kępień
Quoted 64 lines
-----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 EnhancementsQuoted 11 lines
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.
Quoted 4 lines
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.
Quoted 8 lines
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:
Quoted 10 lines
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.
Quoted 3 lines
b) The mechanism to expose WMI devices to userspace must allow for atomic operation, which would exclude a sysfs interface involving multiple
Quoted 8 lines
files.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 25 lines
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.
Quoted 3 lines
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.handacpi/video.hall 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ń
Quoted 9 lines · On Thursday 13 April 2017 13:29:41 [email protected] wrote:
Quoted 3 lines
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?
Quoted 10 lines
Quoted 2 lines
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?
Signature · 2 lines
Pali Rohár [email protected]
Quoted 26 lines · Pali Rohár
Quoted 9 lines · On Thursday 13 April 2017 13:29:41 [email protected] wrote:
Quoted 3 lines
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?
Quoted 6 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 56 lines
-----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 EnhancementsQuoted 4 lines · Pali Rohár
Quoted 3 lines · On Thursday 13 April 2017 13:29:41 [email protected] wrote:
Quoted 3 lines
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.
Quoted 6 lines
Quoted 6 lines
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.
Quoted 18 lines
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?
Quoted 8 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 2 lines
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:
Quoted 5 lines
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.
Quoted 56 lines · On Thu, Apr 13, 2017 at 03:40:08PM +0000, [email protected] wrote:
Quoted 56 lines
-----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 EnhancementsQuoted 4 lines · Pali Rohár
Quoted 3 lines · On Thursday 13 April 2017 13:29:41 [email protected] wrote:
Quoted 3 lines
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.
Quoted 6 lines
Quoted 6 lines
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.
Quoted 18 lines
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?
Quoted 8 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 2 lines
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:
Quoted 8 lines
Quoted 5 lines
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.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 22 lines
-----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 EnhancementsQuoted 3 lines · On Thursday 13 April 2017 13:29:41 [email protected] wrote:
Quoted 3 lines
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.
Quoted 4 lines
Input notifications are just one aspect that received over WMI. I don't see any reason to move the notifications out of the kernel.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 23 lines
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?
Quoted 8 lines
Quoted 2 lines
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.
Quoted 2 lines
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]
Quoted 8 lines · On Thu, 2017-04-13 at 15:40 +0000, [email protected] wrote:
Quoted 7 lines
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.
Quoted 5 lines
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)?
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
Quoted 20 lines
-----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 EnhancementsQuoted 8 lines · On Thu, 2017-04-13 at 15:40 +0000, [email protected] wrote:
Quoted 7 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 22 lines · Michał Kępień
Quoted 7 lines
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.
Quoted 8 lines
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.
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 8 lines
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:
Quoted 10 lines
Quoted 10 lines
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.
Quoted 10 lines
Quoted 3 lines
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.handacpi/video.hall seem redundant to me).
Quoted 4 lines
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.
Quoted 8 lines · On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
Quoted 5 lines · Michał Kępień
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).
Quoted 6 lines
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.
Signature · 2 lines
Pali Rohár [email protected]
Quoted 12 lines · Pali Rohár
Quoted 11 lines · On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
Quoted 5 lines · Michał Kępień
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.
Quoted 9 lines
Quoted 3 lines
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.
Quoted 17 lines · Andy Lutomirski
Quoted 16 lines · Pali Rohár
Quoted 14 lines · On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
Quoted 5 lines · Michał Kępień
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.
Quoted 8 lines
Quoted 5 lines
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.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 66 lines
-----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 EnhancementsQuoted 11 lines · Michał Kępień
Quoted 11 lines
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.
Quoted 11 lines
Quoted 4 lines
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.
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 8 lines
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:
Quoted 10 lines
Quoted 10 lines
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
Quoted 4 lines
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.
Quoted 21 lines
Quoted 11 lines
Quoted 4 lines
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.handacpi/video.hall seem redundant to me).Quoted 4 lines
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.
Quoted 71 lines · On Thu, Apr 13, 2017 at 8:55 AM, <[email protected]> wrote:
Quoted 66 lines
-----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 EnhancementsQuoted 11 lines · Michał Kępień
Quoted 11 lines
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.
Quoted 11 lines
Quoted 4 lines
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.
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 8 lines
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:
Quoted 10 lines
Quoted 10 lines
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
Quoted 4 lines
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.
Quoted 6 lines
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?
Quoted 4 lines
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.
Quoted 88 lines
-----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 EnhancementsQuoted 8 lines · On Thu, Apr 13, 2017 at 8:55 AM, <[email protected]> wrote:
Quoted 8 lines
-----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
Quoted 15 lines
Quoted 15 lines
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 EnhancementsQuoted 7 lines · Michał Kępień
Quoted 7 lines
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.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 29 lines
Quoted 29 lines
communicate with each other.
Quoted 11 lines
Quoted 4 lines
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.
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 8 lines
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:
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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
Quoted 3 lines
Quoted 3 lines
possibly a devmode to do so by default.
I agree. I don't want too see gnome-whatever-widget talking directly to WMI
and
Quoted 2 lines
Quoted 1 line
confusing the kernel driver for the same thing.
Quoted 8 lines
Quoted 6 lines
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.
Quoted 9 lines
Quoted 5 lines
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.
Quoted 110 lines · On Thu, Apr 13, 2017 at 04:54:25PM +0000, [email protected] wrote:
Quoted 88 lines
-----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 EnhancementsQuoted 8 lines · On Thu, Apr 13, 2017 at 8:55 AM, <[email protected]> wrote:
Quoted 8 lines
-----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
Quoted 15 lines
Quoted 15 lines
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 EnhancementsQuoted 7 lines · Michał Kępień
Quoted 7 lines
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.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 29 lines
Quoted 29 lines
communicate with each other.
Quoted 11 lines
Quoted 4 lines
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.
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 8 lines
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:
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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
Quoted 3 lines
Quoted 3 lines
possibly a devmode to do so by default.
I agree. I don't want too see gnome-whatever-widget talking directly to WMI
and
Quoted 2 lines
Quoted 1 line
confusing the kernel driver for the same thing.
Quoted 8 lines
Quoted 6 lines
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.
Quoted 9 lines
Quoted 5 lines
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.
Quoted 6 lines
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.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 134 lines
-----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 EnhancementsQuoted 5 lines · On Thu, Apr 13, 2017 at 04:54:25PM +0000, [email protected] wrote:
Quoted 5 lines
-----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ńQuoted 1 line
Quoted 1 line
Darren Hart <[email protected]>; Rafael J. Wysocki <[email protected]>;
Len
Quoted 6 lines
Quoted 6 lines
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 EnhancementsQuoted 8 lines
Quoted 8 lines · On Thu, Apr 13, 2017 at 8:55 AM, <[email protected]> wrote:
Quoted 7 lines
Quoted 7 lines
-----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 WysockiQuoted 10 lines
Quoted 10 lines
Quoted 1 line
Quoted 1 line
Len Brown <[email protected]>; Pali Rohár <[email protected]>;
Corentin
Quoted 8 lines
Quoted 8 lines
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 EnhancementsOn Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]>
Quoted 11 lines · wrote:
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
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
Quoted 30 lines
Quoted 30 lines
to
Quoted 29 lines
Quoted 29 lines
communicate with each other.
Quoted 11 lines
Quoted 4 lines
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.
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 8 lines
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:
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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),
Quoted 29 lines
Quoted 7 lines
and
Quoted 3 lines
Quoted 3 lines
possibly a devmode to do so by default.
I agree. I don't want too see gnome-whatever-widget talking directly to WMI
and
Quoted 2 lines
Quoted 1 line
confusing the kernel driver for the same thing.
Quoted 8 lines
Quoted 6 lines
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.
Quoted 9 lines
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
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.
Quoted 15 lines · On Thu, Apr 13, 2017 at 10:39 AM, <[email protected]> wrote:
Quoted 10 lines
-----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 EnhancementsWell 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).
Quoted 6 lines
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 :)
Quoted 32 lines
-----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 EnhancementsQuoted 19 lines · On Thu, Apr 13, 2017 at 10:39 AM, <[email protected]> wrote:
Quoted 10 lines
-----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 EnhancementsWell 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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 20 lines · On Thursday 13 April 2017 17:39:56 [email protected] wrote:
Quoted 7 lines
Quoted 6 lines
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.
Quoted 8 lines
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).
Quoted 5 lines
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.
Signature · 2 lines
Pali Rohár [email protected]
Quoted 27 lines · Pali Rohár
Quoted 20 lines · On Thursday 13 April 2017 17:39:56 [email protected] wrote:
Quoted 7 lines
Quoted 6 lines
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.
Quoted 8 lines
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).
Quoted 5 lines
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.
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
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,
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 51 lines · On Tuesday 18 April 2017 18:56:31 Darren Hart wrote:
Quoted 31 lines · Pali Rohár
Quoted 23 lines · On Thursday 13 April 2017 17:39:56 [email protected] wrote:
Quoted 11 lines
Quoted 6 lines
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.
Quoted 6 lines
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).
Quoted 6 lines
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.
Quoted 8 lines
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.
Quoted 1 line
It's not ideal - but I believe it addresses our reality.
Ok.
Quoted 11 lines
Quoted 5 lines
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.
Quoted 7 lines
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
Quoted 6 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 8 lines
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.
Quoted 5 lines
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.
Signature · 2 lines
Pali Rohár [email protected]
Quoted 71 lines · On Thu, Apr 13, 2017 at 03:55:01PM +0000, [email protected] wrote:
Quoted 66 lines
-----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 EnhancementsQuoted 11 lines · Michał Kępień
Quoted 11 lines
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.
Quoted 11 lines
Quoted 4 lines
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.
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 8 lines
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:
Quoted 10 lines
Quoted 10 lines
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
Quoted 4 lines
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.
Quoted 7 lines
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.
Quoted 2 lines
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.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 86 lines · Darren Hart
Quoted 71 lines · On Thu, Apr 13, 2017 at 03:55:01PM +0000, [email protected] wrote:
Quoted 66 lines
-----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 EnhancementsQuoted 11 lines · Michał Kępień
Quoted 11 lines
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.
Quoted 11 lines
Quoted 4 lines
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.
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 8 lines
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:
Quoted 10 lines
Quoted 10 lines
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
Quoted 4 lines
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.
Quoted 7 lines
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.
Quoted 7 lines
* 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:
Quoted 120 lines
-----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 EnhancementsQuoted 8 lines · Darren Hart
Quoted 7 lines · On Thu, Apr 13, 2017 at 03:55:01PM +0000, [email protected] wrote:
Quoted 7 lines
-----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 WysockiQuoted 1 line
Quoted 1 line
Quoted 1 line
Len Brown <[email protected]>; Pali Rohár <[email protected]>;
Corentin
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
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 EnhancementsOn Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <[email protected]>
Quoted 11 lines · wrote:
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
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
Quoted 29 lines
Quoted 29 lines
Quoted 29 lines
communicate with each other.
Quoted 11 lines
Quoted 4 lines
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.
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 8 lines
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:
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
possibly a devmode to do so by default.
I agree. I don't want too see gnome-whatever-widget talking directly to WMI
and
Quoted 16 lines
Quoted 9 lines
Quoted 1 line
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.
Quoted 7 lines
* 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.
Quoted 3 lines
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.
Quoted 10 lines
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
Quoted 69 lines · Andy Lutomirski
Quoted 22 lines · Michał Kępień
Quoted 7 lines
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.
Quoted 8 lines
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.
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 8 lines
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:
Quoted 10 lines
Quoted 10 lines
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.
Quoted 10 lines
Quoted 3 lines
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.handacpi/video.hall seem redundant to me).Quoted 4 lines
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).
Quoted 7 lines
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.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 5 lines · 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, ...
Signature · 2 lines
Pali Rohár [email protected]
Quoted 7 lines · Pali Rohár
Quoted 5 lines · 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.
Quoted 5 lines
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 :-)
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Earlier question from Andy. I had some discussion with the right people about this.
Quoted 1 line
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.
Quoted 10 lines
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.
Quoted 9 lines
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.
Quoted 28 lines · 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.
Quoted 1 line
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.
Quoted 17 lines
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.
Quoted 5 lines
Quoted 2 lines
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?
Quoted 4 lines
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?
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 50 lines
-----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 EnhancementsQuoted 1 line · 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.
Quoted 5 lines
Quoted 2 lines
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
Quoted 11 lines
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.
Quoted 6 lines
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
Quoted 1 line
Quoted 1 line
license selection, and development of new mechanisms in existing standards,
like
Quoted 1 line
Quoted 1 line
ACPI
_DSD. All of these serve to support innovation by removing bottlenecksand
Quoted 7 lines
Quoted 7 lines
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
Quoted 5 lines
Quoted 4 lines
would enable rapid feature enabling.
Perhaps I should have led with this :-)
Quoted 8 lines
Quoted 1 line
So considering future plans, I'd really like if it's possible to expose all the GUID's
the
Quoted 1 line
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.
Quoted 5 lines
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?
Quoted 1 line
Quoted 7 lines
Quoted 1 line
As example is we have some diagnostic testing tools. Having to whitelist
interfaces
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 59 lines · On Fri, Apr 14, 2017 at 05:42:03PM +0000, [email protected] wrote:
Quoted 50 lines
-----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 EnhancementsQuoted 1 line · 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.
Quoted 5 lines
Quoted 2 lines
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
Quoted 11 lines
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.
Quoted 6 lines
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
Quoted 1 line
Quoted 1 line
license selection, and development of new mechanisms in existing standards,
like
Quoted 1 line
Quoted 1 line
ACPI
_DSD. All of these serve to support innovation by removing bottlenecksand
Quoted 7 lines
Quoted 7 lines
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
Quoted 5 lines
Quoted 4 lines
would enable rapid feature enabling.
Perhaps I should have led with this :-)
Quoted 8 lines
Quoted 1 line
So considering future plans, I'd really like if it's possible to expose all the GUID's
the
Quoted 1 line
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?
Quoted 12 lines
My preference would be to expose everything found in
_WDGacross 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.Quoted 3 lines
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.
Quoted 25 lines
Quoted 9 lines
Quoted 3 lines
As example is we have some diagnostic testing tools. Having to whitelist
interfaces
Quoted 2 lines
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.
Quoted 5 lines
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.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 109 lines
-----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 EnhancementsQuoted 8 lines · On Fri, Apr 14, 2017 at 05:42:03PM +0000, [email protected] wrote:
Quoted 8 lines
-----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];Quoted 5 lines
Quoted 5 lines
[email protected]; [email protected]; linux- [email protected]
Subject: Re: RFC: WMI EnhancementsOn Thu, Apr 13, 2017 at 08:38:28PM +0000, [email protected]
Quoted 6 lines · wrote:
Quoted 6 lines
Quoted 1 line
Earlier question from Andy. I had some discussion with the right people about
this.
Quoted 4 lines
Quoted 2 lines
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
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
splitting up data access and organization of that data access classes across
multiple
Quoted 3 lines
other GUID/method pairs in the future.
Ideally this could be done without needing kernel patches every time a new
GUID
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
would (essentially) need to be whitelisted.
Quoted 1 line
I am a strong supporter of the following philosophy with respect to
supporting
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
development, open-first policy toward specifications and documentation,
proper
Quoted 1 line
Quoted 1 line
license selection, and development of new mechanisms in existing
standards,
Quoted 7 lines
Quoted 7 lines
like
Quoted 1 line
Quoted 1 line
ACPI
_DSD. All of these serve to support innovation by removing bottlenecksand
Quoted 4 lines
Quoted 4 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
vendor has a feature they want to expose which they determine to be a
value
Quoted 9 lines
Quoted 9 lines
Quoted 2 lines
Quoted 2 lines
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
Quoted 6 lines
Quoted 4 lines
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
Quoted 9 lines
Quoted 7 lines
the
Quoted 1 line
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
_WDGacross platforms soit
Quoted 1 line
doesn't have to be a whitelist. DMI matching could work if it was done
specifically
Quoted 3 lines
on the manufacturer rather than individual system.
If you compare to how it's done with the other OS, everything mentioned in the
MOF
Quoted 7 lines
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.Quoted 3 lines
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" #defineDELL_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.
Quoted 8 lines
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.
Quoted 24 lines · Darren Hart
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:
Quoted 10 lines
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
Quoted 36 lines · Rafael Wysocki
Quoted 24 lines · Darren Hart
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:
Quoted 10 lines
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.
Quoted 9 lines
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.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 65 lines · Darren Hart
Quoted 36 lines · Rafael Wysocki
Quoted 24 lines · Darren Hart
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:
Quoted 10 lines
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.
Quoted 9 lines
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.
Quoted 2 lines
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.
Quoted 73 lines · Andy Lutomirski
Quoted 65 lines · Darren Hart
Quoted 36 lines · Rafael Wysocki
Quoted 24 lines · Darren Hart
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:
Quoted 10 lines
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.
Quoted 9 lines
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.
Quoted 2 lines
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.
Quoted 7 lines
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.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 67 lines · Darren Hart
Quoted 66 lines · Andy Lutomirski
Quoted 65 lines · Darren Hart
Quoted 36 lines · Rafael Wysocki
Quoted 24 lines · Darren Hart
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:
Quoted 10 lines
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.
Quoted 9 lines
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.
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 13 lines
Quoted 7 lines
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.
Quoted 5 lines
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
Quoted 75 lines · Rafael Wysocki
Quoted 67 lines · Darren Hart
Quoted 66 lines · Andy Lutomirski
Quoted 65 lines · Darren Hart
Quoted 36 lines · Rafael Wysocki
Quoted 24 lines · Darren Hart
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:
Quoted 10 lines
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.
Quoted 9 lines
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.
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 6 lines
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
Quoted 24 lines
Quoted 14 lines
Quoted 8 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
This looks similar to exposing
_DSMfunctionality for certain device to user space where some functions of the_DSMin 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_DSMon 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.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 96 lines · On Tuesday 18 April 2017 18:33:25 Darren Hart wrote:
Quoted 95 lines · Rafael Wysocki
Quoted 83 lines · Darren Hart
Quoted 82 lines · Andy Lutomirski
Quoted 80 lines · Darren Hart
Quoted 47 lines · Rafael Wysocki
Quoted 30 lines · Darren Hart
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:
Quoted 13 lines
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.
Quoted 8 lines
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.
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 33 lines
Quoted 25 lines
Quoted 14 lines
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
This looks similar to exposing
_DSMfunctionality for certain device to user space where some functions of the_DSMin 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_DSMon behalf of user space).
Quoted 6 lines
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.
Quoted 23 lines
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.cadds 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 requestwmi.cto 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.
Signature · 2 lines
Pali Rohár [email protected]
Quoted 158 lines · Pali Rohár
Quoted 96 lines · On Tuesday 18 April 2017 18:33:25 Darren Hart wrote:
Quoted 95 lines · Rafael Wysocki
Quoted 83 lines · Darren Hart
Quoted 82 lines · Andy Lutomirski
Quoted 80 lines · Darren Hart
Quoted 47 lines · Rafael Wysocki
Quoted 30 lines · Darren Hart
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:
Quoted 13 lines
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.
Quoted 8 lines
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.
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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 :-DIMO, this will only results in more problems as we already have and does not bring any value. Just anarchy, like in windows world.
Quoted 33 lines
Quoted 25 lines
Quoted 14 lines
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
This looks similar to exposing
_DSMfunctionality for certain device to user space where some functions of the_DSMin 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_DSMon behalf of user space).Quoted 6 lines
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.
Quoted 3 lines
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).
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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,
Quoted 28 lines
Quoted 24 lines
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.cadds 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 requestwmi.cto 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.
Signature · 2 lines
Pali Rohár [email protected]
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 10 lines · On Tuesday 18 April 2017 15:49:31 Darren Hart wrote:
Quoted 3 lines · Pali Rohár
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...
Quoted 2 lines
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.
Quoted 43 lines
For example,
dell-wmi.cwould be largely unaffected as theEVENT_GUIDis 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 fordell-wmi-aio.cFor
dell-wmi-led.c, we could most likely not export the GUID at all, but if we did, we could choose to filter ondevice_idor command from thebios_argsused 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_WMIGUID calls equivalent to "class 17, select 11" (Wireless control), since that is handled internally. Similarly for "4,11" (KBD ALS).Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
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.
Quoted 8 lines
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...
Signature · 2 lines
Pali Rohár [email protected]
Quoted 119 lines
-----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 EnhancementsQuoted 10 lines · On Tuesday 18 April 2017 15:49:31 Darren Hart wrote:
Quoted 3 lines · Pali Rohár
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...
Quoted 2 lines
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.
Quoted 43 lines
For example,
dell-wmi.cwould be largely unaffected as theEVENT_GUIDis 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 fordell-wmi-aio.cFor
dell-wmi-led.c, we could most likely not export the GUID at all, but if we did, we could choose to filter ondevice_idor command from thebios_argsused 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_WMIGUID calls equivalent to "class 17, select 11" (Wireless control), since that is handled internally. Similarly for "4,11" (KBD ALS).Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
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.
Quoted 2 lines
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
Quoted 3 lines
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
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 8 lines · On Wednesday 19 April 2017 18:29:53 [email protected] wrote:
Quoted 2 lines
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.
Signature · 2 lines
Pali Rohár [email protected]
Quoted 24 lines
-----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 EnhancementsQuoted 8 lines · On Wednesday 19 April 2017 18:29:53 [email protected] wrote:
Quoted 2 lines
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.
Quoted 10 lines
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).
Quoted 35 lines · On Wednesday 19 April 2017 17:24:00 [email protected] wrote:
Quoted 24 lines
-----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 EnhancementsQuoted 8 lines · On Wednesday 19 April 2017 18:29:53 [email protected] wrote:
Quoted 2 lines
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.
Quoted 10 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 7 lines
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?
Signature · 2 lines
Pali Rohár [email protected]
Quoted 36 lines · Pali Rohár
Quoted 35 lines · On Wednesday 19 April 2017 17:24:00 [email protected] wrote:
Quoted 34 lines
-----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 EnhancementsQuoted 8 lines · On Wednesday 19 April 2017 18:29:53 [email protected] wrote:
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 4 lines
Quoted 3 lines
This audience recommends the way for users to configure the system but of course cannot stop users from doing what they decide to do.
Quoted 17 lines
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.
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
Signature · 3 lines
-- Pali Rohár [email protected]
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 84 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Thursday, April 20, 2017 3:45 PM
To: Pali Rohár <[email protected]>
Cc: Limonciello, Mario <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; [email protected]; linux- [email protected]
Subject: Re: RFC: WMI EnhancementsQuoted 36 lines · Pali Rohár
Quoted 35 lines · On Wednesday 19 April 2017 17:24:00 [email protected] wrote:
Quoted 34 lines
-----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 EnhancementsQuoted 8 lines · On Wednesday 19 April 2017 18:29:53 [email protected] wrote:
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 4 lines
Quoted 3 lines
This audience recommends the way for users to configure the system but of course cannot stop users from doing what they decide to do.
Quoted 17 lines
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.
Quoted 7 lines
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.
Quoted 6 lines
There have been exceptions for specific pseudo filesystems and such, but they are rare. We would need to document the WMI commitment from the kernel to userspace (e.g. any call may be filtered based on current Linux kernel WMI usage, which may change over time). This sounds troublesome... will give this some more thought.
There are other examples in the kernel of the same data accessible in multiple different methods that can cause inconsistencies too.
Quoted 7 lines
Quoted 6 lines
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?
Quoted 5 lines
It might be moot with Christoph's dynamic ID comment which I need to go review in detail. Putting that aside for a moment, what I intended was for the platform driver to whitelist GUIDs. But, that doesn't necessarily mean it has an explicit list. The platform driver could have a blacklist and then walk through all available GUIDs and export everything except those on the blacklist.
To get this started can you re-review Andy's platform/wmi tree and merge in some of his bus work? Regardless of the outcome of the access to userspace and dynamic binding this is a good direction for WMI support in platform/drivers/x86 to get started.
Quoted 7 lines
Now with Christoph's idea, we may be able to maintain a blacklist of GUIDs and a whitelist of platforms which CAN export WMI, but not export any until userspace requests a specific GUID be exported at which point it is checked against the blacklist and then exported accordingly, at which point the WMI method filters handle the rest.
I've been studying more about how this access to WMI BIOS functions on Windows works this week and uncovered what I see as another set of related questions around commitment to manageability access from the OS with this potential userspace layer.
On Windows what happens is the MOF data (same stuff exposed by Andy's wmi-mof) is imported into the WMI namespace. This allows any tools to know exactly how to interact with the various GUID's associated to the ASL methods. The format of the data and the arguments supported are encoded directly in that MOF data.
This means that standard WBEM tools are able to interact directly with these methods based upon exposed objects. BIOS manufacturer can expose say all BIOS settings that are integer to a GUID for interacting with integer settings and those would get loaded into the WMI namespace. When someone uses a WBEM tool to modify that object the data is properly formatted into the correct arguments for an integer and then run through the ASL. Another GUID might be made for strings and another for specially crafted lists (like a boot order). The important part is that all settings are discoverable and no extra tools are needed to administer a box. It can all be done from things like PowerShell or wmic.
In an ideal world I think this is the right solution for Linux too, as part of this pipe we've discussed let some userspace Linux WBEM tools like OpenLMI have access to a BIOS provider that can interact with various settings.
Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF" which has been pre-compiled to an intermediate format with mofcomp.exe on Windows. The format of binary MOF is not documented and the only known way to get text mof back out is by using mofcomp.exe with some esoteric arguments.
mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409 binary_mof_file
So with that said, what role should the Linux kernel actually play here?
My thought is it still makes sense to make this pipe available to potentially enable WBEM tools at some point. At least until a way to deconstruct binary MOF is made available, it's conceivable to build a provider from reverse engineered discovery of how the ASL works, it just won't be as "pretty" as the type of data you get out of MOF with name and value mappings.
Quoted 91 lines · On Fri, May 05, 2017 at 09:55:46PM +0000, [email protected] wrote:
Quoted 84 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Thursday, April 20, 2017 3:45 PM
To: Pali Rohár <[email protected]>
Cc: Limonciello, Mario <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; [email protected]; linux- [email protected]
Subject: Re: RFC: WMI EnhancementsQuoted 36 lines · Pali Rohár
Quoted 35 lines · On Wednesday 19 April 2017 17:24:00 [email protected] wrote:
Quoted 34 lines
-----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 EnhancementsQuoted 8 lines · On Wednesday 19 April 2017 18:29:53 [email protected] wrote:
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 4 lines
Quoted 3 lines
This audience recommends the way for users to configure the system but of course cannot stop users from doing what they decide to do.
Quoted 17 lines
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.
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
There are other examples in the kernel of the same data accessible in multiple different methods that can cause inconsistencies too.
Something that occurred to me today is we could include in the API of the WMI device the potential return of -EBUSY anytime the kernel decides it can't safely service a call. This would avoid *changing* the API exposed to userspace, but it could change the behavior and availability of certain methods.
Quoted 14 lines
Quoted 8 lines
Quoted 7 lines
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?
Quoted 5 lines
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.
Quoted 3 lines
To get this started can you re-review Andy's platform/wmi tree and merge in some of his bus work? Regardless of the outcome of the access to userspace and dynamic binding this is a good direction for WMI support in platform/drivers/x86 to get started.
Yes, this is already queued up for next week, and will be targeted at the 4.13 merge window.
Quoted 18 lines
Quoted 8 lines
Now with Christoph's idea, we may be able to maintain a blacklist of GUIDs and a whitelist of platforms which CAN export WMI, but not export any until userspace requests a specific GUID be exported at which point it is checked against the blacklist and then exported accordingly, at which point the WMI method filters handle the rest.
I've been studying more about how this access to WMI BIOS functions on Windows works this week and uncovered what I see as another set of related questions around commitment to manageability access from the OS with this potential userspace layer.
On Windows what happens is the MOF data (same stuff exposed by Andy's wmi-mof) is imported into the WMI namespace. This allows any tools to know exactly how to interact with the various GUID's associated to the ASL methods. The format of the data and the arguments supported are encoded directly in that MOF data.
Quoted 9 lines
This means that standard WBEM tools are able to interact directly with these methods based upon exposed objects. BIOS manufacturer can expose say all BIOS settings that are integer to a GUID for interacting with integer settings and those would get loaded into the WMI namespace. When someone uses a WBEM tool to modify that object the data is properly formatted into the correct arguments for an integer and then run through the ASL. Another GUID might be made for strings and another for specially crafted lists (like a boot order). The important part is that all settings are discoverable and no extra tools are needed to administer a box. It can all be done from things like PowerShell or wmic.
Ah, that's good insight, thank you.
Quoted 5 lines
In an ideal world I think this is the right solution for Linux too, as part of this pipe we've discussed let some userspace Linux WBEM tools like OpenLMI have access to a BIOS provider that can interact with various settings.
Quoted 7 lines
Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF" which has been pre-compiled to an intermediate format with mofcomp.exe on Windows. The format of binary MOF is not documented and the only known way to get text mof back out is by using mofcomp.exe with some esoteric arguments.
mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
binary_mof_file
Oh wow. That's... that's just horrible. :-(
Do you have an idea as to the relative complexity of this format? Does it make sense for us to attempt to decompile it? Presumably this would be done in userspace ... although seeing as how we have drivers using this functionality, it would be useful to be able to parse this from the kernel as well. Hrm.
Definitely *not* a perfect world :-)
Quoted 1 line
So with that said, what role should the Linux kernel actually play here?
Time to level this up. I'll draft something up and try to get Linus and Greg to weigh in.
Quoted 4 lines
My thought is it still makes sense to make this pipe available to potentially enable WBEM tools at some point. At least until a way to deconstruct binary MOF is made available, it's conceivable to build a provider from reverse engineered discovery of how the ASL works, it just won't be as "pretty" as the type of data you get out of MOF with name and value mappings.
I'm not following the "At least until a way to deconstruct binary MOF is made available" relates to making the pipe as you called it available?
The pipe would provide a WMI chardev which usespace could open and write a method ID and arguments to, and read a response. That is necessary whether or not the MOF data is legible. Having the MOF data just means it's less work to figure out exactly which method IDs are available and what arguments they accept. Right?
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 130 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Friday, May 5, 2017 6:45 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 EnhancementsQuoted 12 lines · On Fri, May 05, 2017 at 09:55:46PM +0000, [email protected] wrote:
Quoted 12 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Thursday, April 20, 2017 3:45 PM
To: Pali Rohár <[email protected]>
Cc: Limonciello, Mario <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; [email protected]; linux- [email protected]
Subject: Re: RFC: WMI EnhancementsOn Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · On Wednesday 19 April 2017 17:24:00 [email protected] wrote:
Quoted 7 lines
Quoted 7 lines
-----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-
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
[email protected]; [email protected]
Subject: Re: RFC: WMI EnhancementsOn Wednesday 19 April 2017 18:29:53 [email protected]
Quoted 55 lines · wrote:
Quoted 55 lines
Quoted 24 lines
Quoted 24 lines
Quoted 23 lines
Quoted 8 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 21 lines
Quoted 3 lines
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.
Quoted 7 lines
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).Quoted 2 lines
Quoted 2 lines
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
Quoted 1 line
Quoted 1 line
approach which I certainly appreciate, we have a very strong position that we
do
Quoted 11 lines
Quoted 8 lines
not break userspace.
There have been exceptions for specific pseudo filesystems and such, but they are rare. We would need to document the WMI commitment from the kernel to userspace (e.g. any call may be filtered based on current Linux kernel WMI usage, which may change over time). This sounds troublesome... will give this some more thought.
There are other examples in the kernel of the same data accessible in multiple different methods that can cause inconsistencies too.
Something that occurred to me today is we could include in the API of the WMI device the potential return of
-EBUSYanytime the kernel decides it can't safely service a call. This would avoid *changing* the API exposed to userspace, but it could change the behavior and availability of certain methods.Quoted 9 lines
Quoted 9 lines
Quoted 7 lines
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
Quoted 6 lines
Quoted 4 lines
in detail. Putting that aside for a moment, what I intended was for the platform driver to whitelist GUIDs. But, that doesn't necessarily mean it has an explicit list. The platform driver could have a blacklist and then walk through all available GUIDs and export everything except those on the blacklist.
To get this started can you re-review Andy's platform/wmi tree and merge in
Quoted 9 lines
some
Quoted 1 line
of his bus work? Regardless of the outcome of the access to userspace and
dynamic
Quoted 1 line
binding this is a good direction for WMI support in platform/drivers/x86 to get
started.
Yes, this is already queued up for next week, and will be targeted at the 4.13 merge window.
OK great.
Quoted 56 lines
Quoted 3 lines
Quoted 3 lines
Now with Christoph's idea, we may be able to maintain a blacklist of GUIDs and
a
Quoted 1 line
Quoted 1 line
whitelist of platforms which CAN export WMI, but not export any until
userspace
Quoted 6 lines
Quoted 4 lines
requests a specific GUID be exported at which point it is checked against the blacklist and then exported accordingly, at which point the WMI method filters handle the rest.
I've been studying more about how this access to WMI BIOS functions on
Windows
Quoted 1 line
works this week and uncovered what I see as another set of related questions
around
Quoted 1 line
commitment to manageability access from the OS with this potential userspace
layer.
Quoted 2 lines
On Windows what happens is the MOF data (same stuff exposed by Andy's wmi-
mof)
Quoted 2 lines
is imported into the WMI namespace. This allows any tools to know exactly how to interact with the various GUID's associated to the ASL methods. The format of
the
Quoted 3 lines
data and the arguments supported are encoded directly in that MOF data.
This means that standard WBEM tools are able to interact directly with these
methods
Quoted 1 line
based upon exposed objects. BIOS manufacturer can expose say all BIOS settings
that
Quoted 1 line
are integer to a GUID for interacting with integer settings and those would get
loaded
Quoted 1 line
into the WMI namespace. When someone uses a WBEM tool to modify that
object
Quoted 1 line
the data is properly formatted into the correct arguments for an integer and then
run
Quoted 1 line
through the ASL. Another GUID might be made for strings and another for
specially
Quoted 1 line
crafted lists (like a boot order). The important part is that all settings are
discoverable
Quoted 1 line
and no extra tools are needed to administer a box. It can all be done from things
like
Quoted 1 line
PowerShell or wmic.
Ah, that's good insight, thank you.
Quoted 2 lines
In an ideal world I think this is the right solution for Linux too, as part of this pipe
we've
Quoted 1 line
discussed let some userspace Linux WBEM tools like OpenLMI have access to a
BIOS
Quoted 3 lines
provider that can interact with various settings.
Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF"
which
Quoted 1 line
has been pre-compiled to an intermediate format with mofcomp.exe on
Windows.
Quoted 8 lines
Quoted 4 lines
The format of binary MOF is not documented and the only known way to get text mof back out is by using mofcomp.exe with some esoteric arguments.
mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
binary_mof_fileQuoted 1 line
Oh wow. That's... that's just horrible. :-(
That's only because a researcher discovered it too. MS doesn't formally provide any documented support for extracting from binary MOF.
Quoted 6 lines
Do you have an idea as to the relative complexity of this format? Does it make sense for us to attempt to decompile it? Presumably this would be done in userspace ... although seeing as how we have drivers using this functionality, it would be useful to be able to parse this from the kernel as well. Hrm.
I haven't done any analysis of it so I'm not really sure how complex it will be. For now I'd say userspace should be planned to handle it until someone determines A simple enough way to decompile it that can live in the kernel.
Quoted 6 lines
Definitely *not* a perfect world :-)
Quoted 1 line
So with that said, what role should the Linux kernel actually play here?
Time to level this up. I'll draft something up and try to get Linus and Greg to weigh in.
OK thanks.
Quoted 10 lines
Quoted 2 lines
My thought is it still makes sense to make this pipe available to potentially enable
WBEM
Quoted 1 line
tools at some point. At least until a way to deconstruct binary MOF is made
available,
Quoted 1 line
it's conceivable to build a provider from reverse engineered discovery of how the
ASL works,
Quoted 1 line
it just won't be as "pretty" as the type of data you get out of MOF with name and
value mappings.
Quoted 9 lines
I'm not following the "At least until a way to deconstruct binary MOF is made available" relates to making the pipe as you called it available?
The pipe would provide a WMI chardev which usespace could open and write a method ID and arguments to, and read a response. That is necessary whether or not the MOF data is legible. Having the MOF data just means it's less work to figure out exactly which method IDs are available and what arguments they accept. Right?
I meant that to say that at least for now Andy's wmi-mof driver should still be merged. If something is going to build on top of this to do WBEM tools, they'll need that MOF data once someone figures out how to nicely deconstruct it.
Quoted 11 lines · On Fri, May 5, 2017 at 5:51 PM, <[email protected]> wrote:
Quoted 9 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Friday, May 5, 2017 6:45 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
Quoted 4 lines
I meant that to say that at least for now Andy's wmi-mof driver should still be merged. If something is going to build on top of this to do WBEM tools, they'll need that MOF data once someone figures out how to nicely deconstruct it.
The thing I don't like about my own driver is that, as a WMI device driver, it can be loaded before the rest of the bus finishes probing. So user programs that are notified asynchronously that the wmi-mof driver is loaded and try to use future functionality (ioctl to issue a MOF-based method call?) might end up doing so before the rest of the bus is probed.
This could be addressed by always exposing the wmi-mof device last (sort of -- it can be a module) or perhaps by moving MOF functionality to the core driver. Or maybe it's not really a problem.
Also, isn't there a way to ask Microsoft to document this? Are you supposed to "ask a question" on this forum, perhaps:
https://msdn.microsoft.com/en-us/library/gg134029.aspx
I'm guessing the Samba team knows how to do this, too.
Quoted 24 lines · Andy Lutomirski
Quoted 11 lines · On Fri, May 5, 2017 at 5:51 PM, <[email protected]> wrote:
Quoted 9 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Friday, May 5, 2017 6:45 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 EnhancementsQuoted 4 lines
I meant that to say that at least for now Andy's wmi-mof driver should still be merged. If something is going to build on top of this to do WBEM tools, they'll need that MOF data once someone figures out how to nicely deconstruct it.
The thing I don't like about my own driver is that, as a WMI device driver, it can be loaded before the rest of the bus finishes probing. So user programs that are notified asynchronously that the wmi-mof driver is loaded and try to use future functionality (ioctl to issue a MOF-based method call?) might end up doing so before the rest of the bus is probed.
Quoted 3 lines
This could be addressed by always exposing the wmi-mof device last (sort of -- it can be a module) or perhaps by moving MOF functionality to the core driver. Or maybe it's not really a problem.
Thanks Andy, I'll keep that in mind and see if I can come up with something to address it while working on WMI this week.
The other problem with wmi-mof is that there will be no immediate open source consumers of the interface, and none on the horizon. We can't even test it to any meaningful degree on Linux. I suspect this will be met with stiff resistance.
Quoted 8 lines
Also, isn't there a way to ask Microsoft to document this? Are you supposed to "ask a question" on this forum, perhaps:
https://msdn.microsoft.com/en-us/library/gg134029.aspx
I'm guessing the Samba team knows how to do this, too.
It's a start.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 42 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Monday, May 8, 2017 10:29 AM
To: Andy Lutomirski <[email protected]>
Cc: Limonciello, Mario <[email protected]>; Pali Rohár <[email protected]>; Rafael J. Wysocki <[email protected]>; Len Brown <[email protected]>; Corentin Chary <[email protected]>; Andy Shevchenko <[email protected]>; [email protected]; [email protected]; [email protected]
Subject: Re: RFC: WMI EnhancementsQuoted 12 lines · Andy Lutomirski
Quoted 9 lines · On Fri, May 5, 2017 at 5:51 PM, <[email protected]> wrote:
Quoted 9 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Friday, May 5, 2017 6:45 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 EnhancementsQuoted 1 line
Quoted 1 line
I meant that to say that at least for now Andy's wmi-mof driver should still be
merged.
Quoted 1 line
Quoted 1 line
If something is going to build on top of this to do WBEM tools, they'll need that
MOF
Quoted 10 lines
Quoted 2 lines
data once someone figures out how to nicely deconstruct it.
The thing I don't like about my own driver is that, as a WMI device driver, it can be loaded before the rest of the bus finishes probing. So user programs that are notified asynchronously that the wmi-mof driver is loaded and try to use future functionality (ioctl to issue a MOF-based method call?) might end up doing so before the rest of the bus is probed.
Quoted 3 lines
This could be addressed by always exposing the wmi-mof device last (sort of -- it can be a module) or perhaps by moving MOF functionality to the core driver. Or maybe it's not really a problem.
Quoted 7 lines
Thanks Andy, I'll keep that in mind and see if I can come up with something to address it while working on WMI this week.
The other problem with wmi-mof is that there will be no immediate open source consumers of the interface, and none on the horizon. We can't even test it to any meaningful degree on Linux. I suspect this will be met with stiff resistance.
Well FWIW I did a quick PoC check with the binary that I got out of it to make sure it matched what was supposed to be. I brought it over to a Win10 box and decompiled using the mofcmp tool and those crazy arguments I mentioned and it was correct.
I'd argue that even if there is no open source tools available today, not making the data available to userspace makes it difficult to even attempt to start to reverse engineer.
Kernel config with default of "N" perhaps for wmi-mof?
Quoted 9 lines
Quoted 9 lines
Also, isn't there a way to ask Microsoft to document this? Are you supposed to "ask a question" on this forum, perhaps:
https://msdn.microsoft.com/en-us/library/gg134029.aspx
I'm guessing the Samba team knows how to do this, too.
Microsoft treats this as an "intermediary" format. I'm not convinced that anyone other than MS knows anything about it today.
I agree asking them to document it is probably the right way to go.
Quoted 55 lines · On Mon, May 08, 2017 at 03:36:31PM +0000, [email protected] wrote:
Quoted 42 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Monday, May 8, 2017 10:29 AM
To: Andy Lutomirski <[email protected]>
Cc: Limonciello, Mario <[email protected]>; Pali Rohár <[email protected]>; Rafael J. Wysocki <[email protected]>; Len Brown <[email protected]>; Corentin Chary <[email protected]>; Andy Shevchenko <[email protected]>; [email protected]; [email protected]; [email protected]
Subject: Re: RFC: WMI EnhancementsQuoted 12 lines · Andy Lutomirski
Quoted 9 lines · On Fri, May 5, 2017 at 5:51 PM, <[email protected]> wrote:
Quoted 9 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Friday, May 5, 2017 6:45 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 EnhancementsQuoted 1 line
Quoted 1 line
I meant that to say that at least for now Andy's wmi-mof driver should still be
merged.
Quoted 1 line
Quoted 1 line
If something is going to build on top of this to do WBEM tools, they'll need that
MOF
Quoted 10 lines
Quoted 2 lines
data once someone figures out how to nicely deconstruct it.
The thing I don't like about my own driver is that, as a WMI device driver, it can be loaded before the rest of the bus finishes probing. So user programs that are notified asynchronously that the wmi-mof driver is loaded and try to use future functionality (ioctl to issue a MOF-based method call?) might end up doing so before the rest of the bus is probed.
Quoted 3 lines
This could be addressed by always exposing the wmi-mof device last (sort of -- it can be a module) or perhaps by moving MOF functionality to the core driver. Or maybe it's not really a problem.
Quoted 7 lines
Thanks Andy, I'll keep that in mind and see if I can come up with something to address it while working on WMI this week.
The other problem with wmi-mof is that there will be no immediate open source consumers of the interface, and none on the horizon. We can't even test it to any meaningful degree on Linux. I suspect this will be met with stiff resistance.
Well FWIW I did a quick PoC check with the binary that I got out of it to make sure it matched what was supposed to be. I brought it over to a Win10 box and decompiled using the mofcmp tool and those crazy arguments I mentioned and it was correct.
Quoted 5 lines
I'd argue that even if there is no open source tools available today, not making the data available to userspace makes it difficult to even attempt to start to reverse engineer.
Kernel config with default of "N" perhaps for wmi-mof?
All true. There is a precedent we're working against on this. I'll include it in my leveling-up thread today or tomorrow.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Also, isn't there a way to ask Microsoft to document this? Are you supposed to "ask a question" on this forum, perhaps:
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
I'm guessing the Samba team knows how to do this, too.
Microsoft treats this as an "intermediary" format. I'm not convinced that anyone other than MS knows anything about it today.
I agree asking them to document it is probably the right way to go.
Mario, you are most likely in a better position to do that than I am. Would you take that on?
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 90 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Monday, May 8, 2017 10:47 AM
To: Limonciello, Mario <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; platform- [email protected]; [email protected]
Subject: Re: RFC: WMI EnhancementsQuoted 8 lines · On Mon, May 08, 2017 at 03:36:31PM +0000, [email protected] wrote:
Quoted 8 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Monday, May 8, 2017 10:29 AM
To: Andy Lutomirski <[email protected]>
Cc: Limonciello, Mario <[email protected]>; Pali Rohár <[email protected]>; Rafael J. Wysocki <[email protected]>; Len Brown <[email protected]>; Corentin Chary <[email protected]>; Andy Shevchenko <[email protected]>; linux-Quoted 4 lines
Quoted 4 lines
[email protected]; [email protected]
Subject: Re: RFC: WMI EnhancementsOn Fri, May 05, 2017 at 06:25:08PM -0700, Andy Lutomirski wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · On Fri, May 5, 2017 at 5:51 PM, <[email protected]> wrote:
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Friday, May 5, 2017 6:45 PM
To: Limonciello, Mario <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected];platform-
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
[email protected]; [email protected]
Subject: Re: RFC: WMI EnhancementsI meant that to say that at least for now Andy's wmi-mof driver should still
be
Quoted 2 lines
Quoted 2 lines
merged.
Quoted 1 line
Quoted 1 line
If something is going to build on top of this to do WBEM tools, they'll need
that
Quoted 11 lines
Quoted 11 lines
MOF
Quoted 10 lines
Quoted 2 lines
data once someone figures out how to nicely deconstruct it.
The thing I don't like about my own driver is that, as a WMI device driver, it can be loaded before the rest of the bus finishes probing. So user programs that are notified asynchronously that the wmi-mof driver is loaded and try to use future functionality (ioctl to issue a MOF-based method call?) might end up doing so before the rest of the bus is probed.
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
This could be addressed by always exposing the wmi-mof device last (sort of -- it can be a module) or perhaps by moving MOF functionality to the core driver. Or maybe it's not really a problem.
Thanks Andy, I'll keep that in mind and see if I can come up with something to address it while working on WMI this week.
The other problem with wmi-mof is that there will be no immediate open
source
Quoted 9 lines
Quoted 3 lines
consumers of the interface, and none on the horizon. We can't even test it to any meaningful degree on Linux. I suspect this will be met with stiff resistance.
Well FWIW I did a quick PoC check with the binary that I got out of it to make sure it matched what was supposed to be. I brought it over to a Win10 box and decompiled using the mofcmp tool and those crazy arguments I mentioned and it was correct.
Quoted 5 lines
I'd argue that even if there is no open source tools available today, not making the data available to userspace makes it difficult to even attempt to start to reverse engineer.
Kernel config with default of "N" perhaps for wmi-mof?
All true. There is a precedent we're working against on this. I'll include it in my leveling-up thread today or tomorrow.
Quoted 10 lines
Quoted 9 lines
Quoted 9 lines
Also, isn't there a way to ask Microsoft to document this? Are you supposed to "ask a question" on this forum, perhaps:
https://msdn.microsoft.com/en-us/library/gg134029.aspx
I'm guessing the Samba team knows how to do this, too.
Quoted 9 lines
Quoted 5 lines
Microsoft treats this as an "intermediary" format. I'm not convinced that anyone other than MS knows anything about it today.
I agree asking them to document it is probably the right way to go.
Mario, you are most likely in a better position to do that than I am. Would you take that on?
Sure, I've made a request in that forum here:
https://social.msdn.microsoft.com/Forums/en-US/cc3e50d6-c71d-4ce7-b765-6191f1788697/binary-mof-format?forum=os_specifications
I'll keep you apprise if there is any further details provided by MS.
Thanks,
+Cc: Alexander (related to Samba team I suppose, I'm sorry if I'm wrong)
Quoted 33 lines · Darren Hart
Quoted 31 lines · On Mon, May 08, 2017 at 03:36:31PM +0000, [email protected] wrote:
Quoted 18 lines
Quoted 1 line
Quoted 1 line
I meant that to say that at least for now Andy's wmi-mof driver should still be
merged.
Quoted 1 line
Quoted 1 line
If something is going to build on top of this to do WBEM tools, they'll need that
MOF
Quoted 10 lines
Quoted 2 lines
data once someone figures out how to nicely deconstruct it.
The thing I don't like about my own driver is that, as a WMI device driver, it can be loaded before the rest of the bus finishes probing. So user programs that are notified asynchronously that the wmi-mof driver is loaded and try to use future functionality (ioctl to issue a MOF-based method call?) might end up doing so before the rest of the bus is probed.
Quoted 3 lines
This could be addressed by always exposing the wmi-mof device last (sort of -- it can be a module) or perhaps by moving MOF functionality to the core driver. Or maybe it's not really a problem.
Quoted 7 lines
Thanks Andy, I'll keep that in mind and see if I can come up with something to address it while working on WMI this week.
The other problem with wmi-mof is that there will be no immediate open source consumers of the interface, and none on the horizon. We can't even test it to any meaningful degree on Linux. I suspect this will be met with stiff resistance.
Well FWIW I did a quick PoC check with the binary that I got out of it to make sure it matched what was supposed to be. I brought it over to a Win10 box and decompiled using the mofcmp tool and those crazy arguments I mentioned and it was correct.
Quoted 21 lines
Quoted 5 lines
I'd argue that even if there is no open source tools available today, not making the data available to userspace makes it difficult to even attempt to start to reverse engineer.
Kernel config with default of "N" perhaps for wmi-mof?
All true. There is a precedent we're working against on this. I'll include it in my leveling-up thread today or tomorrow.
Quoted 12 lines
Quoted 9 lines
Quoted 9 lines
Also, isn't there a way to ask Microsoft to document this? Are you supposed to "ask a question" on this forum, perhaps:
https://msdn.microsoft.com/en-us/library/gg134029.aspx
I'm guessing the Samba team knows how to do this, too.
Microsoft treats this as an "intermediary" format. I'm not convinced that anyone other than MS knows anything about it today.
Alexander, perhaps you would know someone who may help here?
Quoted 6 lines
Quoted 3 lines
I agree asking them to document it is probably the right way to go.
Mario, you are most likely in a better position to do that than I am. Would you take that on?
Signature · 2 lines
With Best Regards, Andy Shevchenko
A message that is not in the archive (sent off-list or not yet received): CAOg5c--wkQgvsmhTynAKyG9iWaHjRWC5Z+MXzVJVw66vxSz4Zw@mail.gmail.com
(Responding as plain text, your email probably got punted from the ML from being HTML)
Quoted 8 lines
...
I'm not sure what you are asking about. Samba does not deal with WMI at all. The state of affairs is explained at https://powershell.org/2015/04/24/management-information-the-omicimwmimidmtf-dictionary/
-- old WMI (DCOM/RPC-based) is deprecated, new WMI based on WS-MAN is supported and OMI is the implementation. We used to have a very limited attemt at writing DCOM stack and nobody worked on it for years so it got removed.
Thanks! That was a very interesting read.
Quoted 2 lines
Microsoft has already published a MOF parser as part of OMI work: https://github.com/Microsoft/omi/
under MIT license.
Unfortunately that's expecting text MOF, not this intermediary compiled format.
Quoted 11 lines · On Mon, May 08, 2017 at 06:26:53PM +0000, [email protected] wrote:
(Responding as plain text, your email probably got punted from the ML from being HTML)
Quoted 8 lines
...
I'm not sure what you are asking about. Samba does not deal with WMI at all. The state of affairs is explained at https://powershell.org/2015/04/24/management-information-the-omicimwmimidmtf-dictionary/
-- old WMI (DCOM/RPC-based) is deprecated, new WMI based on WS-MAN is supported and OMI is the implementation. We used to have a very limited attemt at writing DCOM stack and nobody worked on it for years so it got removed.
Quoted 7 lines
Thanks! That was a very interesting read.
Quoted 2 lines
Microsoft has already published a MOF parser as part of OMI work: https://github.com/Microsoft/omi/
under MIT license.Unfortunately that's expecting text MOF, not this intermediary compiled format.
I presume which of these to use is the decision of the vendor? Is there a transition going on from BMOF to Text MOF? Or will both be part of products for the near term?
I'm trying to understand if BMOF is a legacy thing now, or if it will continue to be used in new designs.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Quoted 30 lines
-----Original Message-----
From: Darren Hart [mailto:[email protected]]
Sent: Monday, May 8, 2017 2:09 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]; [email protected]; linux- [email protected]
Subject: Re: RFC: WMI EnhancementsQuoted 1 line · On Mon, May 08, 2017 at 06:26:53PM +0000, [email protected] wrote:
(Responding as plain text, your email probably got punted from the ML from
being HTML)
Quoted 5 lines
Quoted 5 lines
...
I'm not sure what you are asking about. Samba does not deal with WMI at all.
The state of affairs is
Quoted 1 line
Quoted 1 line
explained at https://powershell.org/2015/04/24/management-information-
the-omicimwmimidmtf-dictionary/
Quoted 1 line
Quoted 1 line
-- old WMI (DCOM/RPC-based) is deprecated, new WMI based on WS-MAN is
supported and OMI is the
Quoted 1 line
Quoted 1 line
implementation. We used to have a very limited attemt at writing DCOM stack
and nobody worked on
Quoted 4 lines
Quoted 1 line
it for years so it got removed.
Thanks! That was a very interesting read.
Quoted 8 lines
Quoted 1 line
Quoted 1 line
Microsoft has already published a MOF parser as part of OMI work:
https://github.com/Microsoft/omi/
Quoted 4 lines
Quoted 1 line
under MIT license.
Unfortunately that's expecting text MOF, not this intermediary compiled format.
I presume which of these to use is the decision of the vendor?
No, MS documentation indicates to store binary MOF in the ACPI buffer.
Quoted 4 lines
Is there a
transition going on from BMOF to Text MOF? Or will both be part of products for the near term?
Binary MOF will be part of products unless MS or a standards group decides to announce something new for OEM's to use in this space.
Quoted 2 lines
I'm trying to understand if BMOF is a legacy thing now, or if it will continue to be used in new designs.
Should be continued to use in new designs.
Quoted 8 lines · On Friday 05 May 2017 23:55:46 [email protected] wrote:
Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF" which has been pre-compiled to an intermediate format with mofcomp.exe on Windows. The format of binary MOF is not documented and the only known way to get text mof back out is by using mofcomp.exe with some esoteric arguments.
mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
binary_mof_file
Looks like that binary MOF file has "well-known" file extension .bmf. File itself starts with magic hader "FOMB" which is in reverse BMOF (binary mof). But I was not able to find any specification nor any other details. As this binary format is dated back to Win9x I guess data would compressed by some old MS compression algorithm (CAB?).
Moreover via tool wmiofck.exe it is possible to generate header file for WMI driver from binary mof file:
wmiofck.exe -hfile.h -m -u file.bmf
And what is interesting that in this file are also comments which looks like comes from that binary mof file.
When I looked into output from mofcomp.exe with above args, that MOF output did not contain comments, so looks like we still can miss something.
See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html
Signature · 2 lines
Pali Rohár [email protected]
Quoted 19 lines
-----Original Message-----
From: Pali Rohár [mailto:[email protected]]
Sent: Monday, May 8, 2017 12:18 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 EnhancementsQuoted 6 lines · On Friday 05 May 2017 23:55:46 [email protected] wrote:
Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF" which has been pre-compiled to an intermediate format with mofcomp.exe on Windows. The format of binary MOF is not documented and the only known way to get text mof back out is by using mofcomp.exe with some esoteric arguments.
Quoted 8 lines
Quoted 2 lines
mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
binary_mof_fileLooks like that binary MOF file has "well-known" file extension .bmf. File itself starts with magic hader "FOMB" which is in reverse BMOF (binary mof). But I was not able to find any specification nor any other details. As this binary format is dated back to Win9x I guess data would compressed by some old MS compression algorithm (CAB?).
Actually comparing a couple of binary MOF files the first 8 look like the header to me.
0x46, 0x4f, 0x4d, 0x42, 0x01, 0x00, 0x00, 0x00
On a compiled Dell binary MOF the next are:
0xed, 0x04, 0x00, 0x00,
This looks like the size of the remaining data after taking out 16 for the headers 4ed = 1261
Total size is 1277
0xd8, 0x15, 0x00, 0x00
Maybe a checksum?
But that first 16 bytes does look like the header structure to me.
Quoted 8 lines
Moreover via tool wmiofck.exe it is possible to generate header file for WMI driver from binary mof file:
wmiofck.exe
-hfile.h-m -u file.bmfAnd what is interesting that in this file are also comments which looks like comes from that binary mof file.
Ah interesting. The "comments" that come out of that are actually what's mapped to the "Description" field in the WMI repository when the binary MOF is loaded.
They are not the developer comments that were placed in the original MOF data. I would suppose those are lost when compiling to binary MOF.
Quoted 6 lines
When I looked into output from mofcomp.exe with above args, that MOF output did not contain comments, so looks like we still can miss something.
See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html
Actually I see wmimofck output to be missing some important bits. For example on a Dell system You'll get a class BFn declared from mofcomp output, but nothing from wmimofck output.
The most important thing that you're really getting out of this MOF is the size, structure and format of the buffer that you would be sending to ASL.
Back to the point we were discussing of a potential filter, the information in the MOF could possibly be very useful to declaring what is going into the filter.
Quoted 36 lines · On Monday 08 May 2017 21:21:45 [email protected] wrote:
Quoted 20 lines
-----Original Message-----
From: Pali Rohár [mailto:[email protected]]
Sent: Monday, May 8, 2017 12:18 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 EnhancementsQuoted 8 lines · On Friday 05 May 2017 23:55:46 [email protected] wrote:
Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF" which has been pre-compiled to an intermediate format with mofcomp.exe on Windows. The format of binary MOF is not documented and the only known way to get text mof back out is by using mofcomp.exe with some esoteric arguments.
mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
binary_mof_fileQuoted 6 lines
Looks like that binary MOF file has "well-known" file extension .bmf. File itself starts with magic hader "FOMB" which is in reverse BMOF (binary mof). But I was not able to find any specification nor any other details. As this binary format is dated back to Win9x I guess data would compressed by some old MS compression algorithm (CAB?).
Actually comparing a couple of binary MOF files the first 8 look like the header to me.
0x46,0x4f,0x4d,0x42,0x01,0x00,0x00,0x00On a compiled Dell binary MOF the next are:
0xed,0x04,0x00,0x00,
Quoted 8 lines
This looks like the size of the remaining data after taking out 16 for the headers 4ed = 1261
Total size is 1277
0xd8,0x15,0x00,0x00
Maybe a checksum?But that first 16 bytes does look like the header structure to me.
Good catch! Your observation for first 12 bytes passes also for my checks.
Next 4 bytes (after possible checksum) at 0x10 are always same:0x44 0x53 0x00 0x01.
And I guess this should be compression header. In time of Win9x Microsoft had own non-standard compression for disks called DoubleSpace. IIRC it was some modification of LZ77 algorithm. And 0x44 0x53 0x00 0x01 is DS01. Maybe it is really DoubleSpace compression used for binary MOF?
I'm going to find specification of that old compression algorithm...
Quoted 9 lines
Quoted 8 lines
Moreover via tool wmiofck.exe it is possible to generate header file for
WMI driver from binary mof file:
wmiofck.exe-hfile.h-m -u file.bmfAnd what is interesting that in this file are also comments which looks like comes from that binary mof file.
Quoted 7 lines
Ah interesting. The "comments" that come out of that are actually what's mapped to the "Description" field in the WMI repository when the binary MOF is loaded.
They are not the developer comments that were placed in the original MOF data. I would suppose those are lost when compiling to binary MOF.
Hm.. right they are present in decompiled MOF file in Description field.
Quoted 10 lines
Quoted 5 lines
When I looked into output from mofcomp.exe with above args, that MOF output did not contain comments, so looks like we still can miss something.
See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html
Actually I see wmimofck output to be missing some important bits. For example on a Dell system You'll get a class BFn declared from mofcomp output, but nothing from wmimofck output.
Quoted 7 lines
The most important thing that you're really getting out of this MOF is the size, structure and format of the buffer that you would be sending to ASL.
Back to the point we were discussing of a potential filter, the information in the MOF could possibly be very useful to declaring what is going into the filter.
In that header file generated by wmiofck.exe I see definitions for BFn. And there are also sizes for BFn buffers, together with some types.
Signature · 2 lines
Pali Rohár [email protected]
Quoted 62 lines
-----Original Message-----
From: Pali Rohár [mailto:[email protected]]
Sent: Monday, May 8, 2017 4:00 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 EnhancementsQuoted 36 lines · On Monday 08 May 2017 21:21:45 [email protected] wrote:
Quoted 20 lines
-----Original Message-----
From: Pali Rohár [mailto:[email protected]]
Sent: Monday, May 8, 2017 12:18 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 EnhancementsQuoted 8 lines · On Friday 05 May 2017 23:55:46 [email protected] wrote:
Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF" which has been pre-compiled to an intermediate format with mofcomp.exe on Windows. The format of binary MOF is not documented and the only known way to get text mof back out is by using mofcomp.exe with some esoteric arguments.
mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
binary_mof_fileQuoted 6 lines
Looks like that binary MOF file has "well-known" file extension .bmf. File itself starts with magic hader "FOMB" which is in reverse BMOF (binary mof). But I was not able to find any specification nor any other details. As this binary format is dated back to Win9x I guess data would compressed by some old MS compression algorithm (CAB?).
Actually comparing a couple of binary MOF files the first 8 look like the header to me.
0x46,0x4f,0x4d,0x42,0x01,0x00,0x00,0x00On a compiled Dell binary MOF the next are:
0xed,0x04,0x00,0x00,Quoted 8 lines
This looks like the size of the remaining data after taking out 16 for the headers 4ed = 1261
Total size is 1277
0xd8,0x15,0x00,0x00
Maybe a checksum?But that first 16 bytes does look like the header structure to me.
Good catch! Your observation for first 12 bytes passes also for my checks.
Next 4 bytes (after possible checksum) at
0x10are always same:0x440x530x000x01.
Quoted 7 lines
And I guess this should be compression header. In time of Win9x Microsoft had own non-standard compression for disks called DoubleSpace. IIRC it was some modification of LZ77 algorithm. And
0x440x530x000x01is DS01. Maybe it is really DoubleSpace compression used for binary MOF?I'm going to find specification of that old compression algorithm...
44 53 looks promising to be quantum compression.
https://en.wikipedia.org/wiki/Quantum_compression
That’s also what 'file' magic detects from it too.
$ file mof.stripped mof.stripped: Quantum archive data
Quoted 33 lines
Quoted 9 lines
Quoted 8 lines
Moreover via tool wmiofck.exe it is possible to generate header file for
WMI driver from binary mof file:
wmiofck.exe-hfile.h-m -u file.bmfAnd what is interesting that in this file are also comments which looks like comes from that binary mof file.
Quoted 7 lines
Ah interesting. The "comments" that come out of that are actually what's mapped to the "Description" field in the WMI repository when the binary MOF is loaded.
They are not the developer comments that were placed in the original MOF data. I would suppose those are lost when compiling to binary MOF.
Hm.. right they are present in decompiled MOF file in Description field.
Quoted 14 lines
Quoted 5 lines
When I looked into output from mofcomp.exe with above args, that MOF output did not contain comments, so looks like we still can miss something.
See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html
Actually I see wmimofck output to be missing some important bits. For example on a Dell system You'll get a class BFn declared from mofcomp output, but nothing from wmimofck output.
The most important thing that you're really getting out of this MOF is the size, structure and format of the buffer that you would be sending to ASL.
Quoted 5 lines
Quoted 3 lines
Back to the point we were discussing of a potential filter, the information in the MOF could possibly be very useful to declaring what is going into the filter.
In that header file generated by wmiofck.exe I see definitions for BFn.
There is a definition but it's missing the format of the argument from what I can tell.
In any case, this will be tangential to this discussion, but useful for reverse engineering the binary mof format.
Quoted 66 lines · On Monday 08 May 2017 23:18:11 [email protected] wrote:
Quoted 66 lines
-----Original Message-----
From: Pali Rohár [mailto:[email protected]]
Sent: Monday, May 8, 2017 4:00 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 EnhancementsQuoted 43 lines · On Monday 08 May 2017 21:21:45 [email protected] wrote:
Quoted 23 lines
-----Original Message-----
From: Pali Rohár [mailto:[email protected]]
Sent: Monday, May 8, 2017 12:18 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 EnhancementsQuoted 9 lines · On Friday 05 May 2017 23:55:46 [email protected] wrote:
Unfortunately the MOF data that comes out of wmi-mof is so called "Binary MOF" which has been pre-compiled to an intermediate format with mofcomp.exe on Windows. The format of binary MOF is not documented and the only known way to get text mof back out is by using mofcomp.exe with some esoteric arguments.
mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof
-Amendment:MS_409binary_mof_fileQuoted 6 lines
Looks like that binary MOF file has "well-known" file extension .bmf. File itself starts with magic hader "FOMB" which is in reverse BMOF (binary mof). But I was not able to find any specification nor any other details. As this binary format is dated back to Win9x I guess data would compressed by some old MS compression algorithm (CAB?).
Actually comparing a couple of binary MOF files the first 8 look like the header to me.
0x46,0x4f,0x4d,0x42,0x01,0x00,0x00,0x00On a compiled Dell binary MOF the next are:
0xed,0x04,0x00,0x00,This looks like the size of the remaining data after taking out 16 for the headers 4ed = 1261
Total size is 1277Quoted 5 lines
0xd8,0x15,0x00,0x00
Maybe a checksum?But that first 16 bytes does look like the header structure to me.
Good catch! Your observation for first 12 bytes passes also for my checks.
Next 4 bytes (after possible checksum) at
0x10are always same:0x440x530x000x01.
Quoted 8 lines
Quoted 8 lines
And I guess this should be compression header. In time of Win9x Microsoft had own non-standard compression for disks called DoubleSpace. IIRC it was some modification of LZ77 algorithm. And
0x440x530x000x01is DS01. Maybe it is really DoubleSpace compression used for binary MOF?I'm going to find specification of that old compression algorithm...
I found dmsdos implementation of that DS compression at:
http://cmp.felk.cvut.cz/~pisa/dmsdos
Then took relevant decompression code and it really decompressed that binary MOF WMI buffer. But still decompressed format is binary, but I now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again "FOMB" magic header.
I pushed my decompression utility here:
https://github.com/pali/bmfdec
So next step is to decode that decompressed binary MOF file.
Quoted 6 lines
44 53 looks promising to be quantum compression.
https://en.wikipedia.org/wiki/Quantum_compressionThat’s also what 'file' magic detects from it too.
$ file mof.stripped mof.stripped: Quantum archive data
Hm... so that Quantum compression is also modification of LZ77. And probably it is same as DoubleSpace format (or use it).
Quoted 46 lines
Quoted 34 lines
Quoted 9 lines
Quoted 8 lines
Moreover via tool wmiofck.exe it is possible to generate header file for
WMI driver from binary mof file:
wmiofck.exe-hfile.h-m -u file.bmfAnd what is interesting that in this file are also comments which looks like comes from that binary mof file.
Quoted 7 lines
Ah interesting. The "comments" that come out of that are actually what's mapped to the "Description" field in the WMI repository when the binary MOF is loaded.
They are not the developer comments that were placed in the original MOF data. I would suppose those are lost when compiling to binary MOF.
Hm.. right they are present in decompiled MOF file in Description field.
Quoted 14 lines
Quoted 5 lines
When I looked into output from mofcomp.exe with above args, that MOF output did not contain comments, so looks like we still can miss something.
See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html
Actually I see wmimofck output to be missing some important bits. For example on a Dell system You'll get a class BFn declared from mofcomp output, but nothing from wmimofck output.
The most important thing that you're really getting out of this MOF is the size, structure and format of the buffer that you would be sending to ASL.
Quoted 6 lines
Quoted 3 lines
Back to the point we were discussing of a potential filter, the information in the MOF could possibly be very useful to declaring what is going into the filter.
In that header file generated by wmiofck.exe I see definitions for BFn.
There is a definition but it's missing the format of the argument from what I can tell.
In any case, this will be tangential to this discussion, but useful for reverse engineering the binary mof format.
Signature · 2 lines
Pali Rohár [email protected]
Quoted 8 lines
I found dmsdos implementation of that DS compression at:
http://cmp.felk.cvut.cz/~pisa/dmsdosThen took relevant decompression code and it really decompressed that binary MOF WMI buffer. But still decompressed format is binary, but I now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again "FOMB" magic header.
Well that's great. Is it possible that this compression is used for every time a class was declared?
Quoted 3 lines
I pushed my decompression utility here:
https://github.com/pali/bmfdec
Did you forget another commit for pulling in arguments and opening a file or were you just putting the whole buffer into pin?
Quoted 4 lines
So next step is to decode that decompressed binary MOF file.
Quoted 1 line
44 53 looks promising to be quantum compression.
Quoted 11 lines · On Tuesday 09 May 2017 01:10:54 [email protected] wrote:
Quoted 8 lines
I found dmsdos implementation of that DS compression at:
http://cmp.felk.cvut.cz/~pisa/dmsdosThen took relevant decompression code and it really decompressed that binary MOF WMI buffer. But still decompressed format is binary, but I now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again "FOMB" magic header.
Well that's great. Is it possible that this compression is used for every time a class was declared?
Looks like not. That decompressed output seems to be not compressed anymore. Just use same magic header.
Now it looks like binary representation of MOF. Where structures and types are encoded by binary sequences.
Quoted 6 lines
Quoted 3 lines
I pushed my decompression utility here:
https://github.com/pali/bmfdecDid you forget another commit for pulling in arguments and opening a file or were you just putting the whole buffer into pin?
Whole BMF file should be on stdin (with that 16 bytes header) and is decompressed on stdout.
Quoted 4 lines
Quoted 4 lines
So next step is to decode that decompressed binary MOF file.
Quoted 1 line
44 53 looks promising to be quantum compression.
So... it is not Quantum compression. BMF content does not pass Quantum header where is number of files (too huge).
Signature · 2 lines
Pali Rohár [email protected]
Quoted 20 lines
-----Original Message-----
From: Pali Rohár [mailto:[email protected]]
Sent: Tuesday, May 9, 2017 2:29 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 EnhancementsQuoted 9 lines · On Tuesday 09 May 2017 01:10:54 [email protected] wrote:
Quoted 8 lines
I found dmsdos implementation of that DS compression at:
http://cmp.felk.cvut.cz/~pisa/dmsdosThen took relevant decompression code and it really decompressed that binary MOF WMI buffer. But still decompressed format is binary, but I now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again "FOMB" magic header.
Quoted 5 lines
Quoted 2 lines
Well that's great. Is it possible that this compression is used for every time a class was declared?
Looks like not. That decompressed output seems to be not compressed anymore. Just use same magic header.
Actually it looks like a new magic header to me after decompressed.
46 4f 4d 42 54 15 00 00 01 00 00 00 01 00 00 00
That's now FOMBT
Quoted 3 lines
Now it looks like binary representation of MOF. Where structures and types are encoded by binary sequences.
Yes, and I notice in here even mentions of the locale (which was required to decompress using mofcomp too).
00000150 08 00 00 00 00 00 00 00 10 00 00 00 4c 00 6f 00 |............L.o.| 00000160 63 00 61 00 6c 00 65 00 00 00 00 00 4d 00 53 00 |c.a.l.e.....M.S.| 00000170 5c 00 30 00 78 00 34 00 30 00 39 00 00 00 00 00 |\.0.x.4.0.9.....|
Quoted 10 lines
Quoted 7 lines
Quoted 4 lines
I pushed my decompression utility here:
https://github.com/pali/bmfdecDid you forget another commit for pulling in arguments and opening a file or were you just putting the whole buffer into pin?
Whole BMF file should be on stdin (with that 16 bytes header) and is decompressed on stdout.
Oh my mistake, that wasn't clear when I glanced at it.
Quoted 8 lines · On Tue, May 9, 2017 at 9:10 PM, <[email protected]> wrote:
Quoted 8 lines
Quoted 7 lines
Quoted 4 lines
Then took relevant decompression code and it really decompressed that binary MOF WMI buffer. But still decompressed format is binary, but I now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again "FOMB" magic header.
Well that's great. Is it possible that this compression is used for every time a class was declared?
Quoted 6 lines
Quoted 2 lines
Looks like not. That decompressed output seems to be not compressed anymore. Just use same magic header.
Actually it looks like a new magic header to me after decompressed.
46 4f 4d 42 54 15 00 00 01 00 00 00 01 00 00 00
That's now FOMBT
I think you just mistakenly take 0x54 as letter when it looks more like
0x000015540x000000010x00000001
from the above dump.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 29 lines
-----Original Message-----
From: Andy Shevchenko [mailto:[email protected]]
Sent: Tuesday, May 9, 2017 2:04 PM
To: Limonciello, Mario <[email protected]>
Cc: Pali Rohár <[email protected]>; [email protected]; Rafael J. Wysocki <[email protected]>; Andy Lutomirski <[email protected]>; Brown, Len <[email protected]>; Corentin Chary <[email protected]>; Andy Lutomirski <[email protected]>; Andy Shevchenko <[email protected]>; [email protected]; Platform Driver <[email protected]>; [email protected]
Subject: Re: RFC: WMI EnhancementsQuoted 8 lines · On Tue, May 9, 2017 at 9:10 PM, <[email protected]> wrote:
Quoted 8 lines
Quoted 7 lines
Quoted 4 lines
Then took relevant decompression code and it really decompressed that binary MOF WMI buffer. But still decompressed format is binary, but I now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again "FOMB" magic header.
Well that's great. Is it possible that this compression is used for every time a class was declared?
Quoted 6 lines
Quoted 2 lines
Looks like not. That decompressed output seems to be not compressed anymore. Just use same magic header.
Actually it looks like a new magic header to me after decompressed.
46 4f 4d 42 54 15 00 00 01 00 00 00 01 00 00 00
That's now FOMBT
Quoted 7 lines
I think you just mistakenly take
0x54as letter when it looks more like
0x000015540x000000010x00000001from the above dump.
Ah, that's true, but second word is different than original was main point. We didn't know what that represented (maybe it's part of magic header).
46 4f 4d 42 01 00 00 00 ed 04 00 00 d8 15 00 000x00000001
Quoted 3 lines
--
With Best Regards,
Andy Shevchenko
Quoted 7 lines · On Tue, May 9, 2017 at 10:16 PM, <[email protected]> wrote:
Quoted 7 lines
Quoted 2 lines
46 4f 4d 42 54 15 00 00 01 00 00 00 01 00 00 00
That's now FOMBTI think you just mistakenly take
0x54as letter when it looks more like
0x00001554
This one looks like offset (or size 5460)
Quoted 10 lines
Quoted 4 lines
0x000000010x00000001from the above dump.
Ah, that's true, but second word is different than original was main point. We didn't know what that represented (maybe it's part of magic header).
46 4f 4d 42 01 00 00 00 ed 04 00 00 d8 15 00 00
0x00000001
0x000015d8
Again, looks like offset (or size).
0x000004ed
Signature · 2 lines
With Best Regards, Andy Shevchenko
I updated my bmfdec.c (git://github.com/pali/bmfdec.git) and here is guessed header description:
/*
* BMF file is compressed by DS-01 algorithm with additional header:
* 4 bytes: 46 4f 4d 42 - 'F' 'O' 'M' 'B'
* 4 bytes: 01 00 00 00 - version 0x01
* 4 bytes: size of compressed data (low endian) without this header
* 4 bytes: size of decompressed data (low endian) without this header */
/*
* Decompressed part of BMF file contains:
* 4 bytes: 46 4f 4d 42 - 'F' 'O' 'M' 'B'
* 4 bytes: N = size of first part (low endian) since beginning
* N-8 bytes: first part data
* 16 bytes: 42 4d 4f 46 51 55 41 4c 46 4c 41 56 4f 52 31 31 - "BMOFQUALFLAVOR11"
* M bytes: second part data of unknown length
*/
First part of decompressed data contains UTF-16 strings terminated by two zero bytes and between two strings are some binary data. Those strings are just literals found in decompiled MOF file, so looks like binary parts just decodes types and MOF language keywords.
And it looks like second part is not required and sometimes missing. It contains only binary data, no idea what is there.
Now somebody with knowledge of MOF language should be able to describe what and how is stored in first part.
Signature · 2 lines
Pali Rohár [email protected]
Quoted 18 lines · On Tuesday 09 May 2017 21:04:15 Andy Shevchenko wrote:
Quoted 9 lines · On Tue, May 9, 2017 at 9:10 PM, <[email protected]> wrote:
Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
Then took relevant decompression code and it really decompressed that binary MOF WMI buffer. But still decompressed format is binary, but I now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again "FOMB" magic header.
Well that's great. Is it possible that this compression is used for every time a class was declared?
Quoted 7 lines
Quoted 2 lines
Looks like not. That decompressed output seems to be not compressed anymore. Just use same magic header.
Actually it looks like a new magic header to me after decompressed.
46 4f 4d 42 54 15 00 00 01 00 00 00 01 00 00 00
That's now FOMBT
Quoted 8 lines
I think you just mistakenly take
0x54as letter when it looks more like
0x000015540x000000010x00000001from the above dump.
I looked at more decompressed BMF dumps from ACPI WMI and they have different 5th and 6th bytes. So they are really not FOMBT.
46 4f 4d 42 26 35 00 00 01 00 00 00 01 00 00 00
46 4f 4d 42 fa 17 00 00 01 00 00 00 01 00 00 00
46 4f 4d 42 8e 11 00 00 01 00 00 00 01 00 00 00
46 4f 4d 42 ac 1b 00 00 01 00 00 00 01 00 00 00
So magic is only FOMB.
Signature · 2 lines
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.
Quoted 83 lines · Darren Hart
Quoted 75 lines · Rafael Wysocki
Quoted 67 lines · Darren Hart
Quoted 66 lines · Andy Lutomirski
Quoted 65 lines · Darren Hart
Quoted 36 lines · Rafael Wysocki
Quoted 24 lines · Darren Hart
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:
Quoted 10 lines
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.
Quoted 9 lines
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.
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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. :-)
Quoted 55 lines
Quoted 24 lines
Quoted 14 lines
Quoted 8 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
This looks similar to exposing
_DSMfunctionality for certain device to user space where some functions of the_DSMin 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_DSMon 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.cadds 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 requestwmi.cto 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).
Quoted 4 lines
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