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

Groups > linux.kernel > #1636758 > unrolled thread

RE: RFC: WMI Enhancements

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-06 00:00 +0200
    Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-05-06 01:50 +0200
      RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-06 03:00 +0200
        Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-05-06 03:30 +0200
          Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-05-08 17:30 +0200
            RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-08 17:40 +0200
              Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-05-08 17:50 +0200
                Re: RFC: WMI Enhancements Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-08 18:10 +0200
                  RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-08 21:00 +0200
                    Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-05-08 21:10 +0200
                      RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-08 21:20 +0200
                RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-08 18:10 +0200
    Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-05-08 19:20 +0200
      RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-08 21:30 +0200
        Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-05-08 23:10 +0200
          RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-08 23:20 +0200
            Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-05-09 00:20 +0200
              RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-09 03:20 +0200
                Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-05-09 09:40 +0200
                  RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-09 20:20 +0200
                    Re: RFC: WMI Enhancements Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-09 21:10 +0200
                      RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-05-09 21:20 +0200
                        Re: RFC: WMI Enhancements Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-09 21:30 +0200
                          Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-05-10 00:40 +0200
                      Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-05-09 21:30 +0200

Page 1 of 2  [1] 2  Next page →

#1636758 — RE: RFC: WMI Enhancements

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Thursday, April 20, 2017 3:45 PM
> To: Pali Rohár <pali.rohar@gmail.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; rjw@rjwysocki.net;
> luto@amacapital.net; len.brown@intel.com; corentin.chary@gmail.com;
> luto@kernel.org; andriy.shevchenko@linux.intel.com; linux-
> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org; linux-
> pm@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
> > On Wednesday 19 April 2017 17:24:00 Mario.Limonciello@dell.com wrote:
> > > > -----Original Message-----
> > > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > > Cc: dvhart@infradead.org; rjw@rjwysocki.net; luto@amacapital.net;
> > > > len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org;
> > > > andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> > > > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> > > > Subject: Re: RFC: WMI Enhancements
> > > >
> > > > On Wednesday 19 April 2017 18:29:53 Mario.Limonciello@dell.com wrote:
> > > > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > > > > will be exported to userspace after communication with vendor.
> > > > >
> > > > > What about GUID's not yet used by kernel drivers?  Would those
> > > > > default to whitelist default to blacklist?  My preference would be
> > > > > to default to whitelist. This allows new GUID's to be added later
> > > > > without needing to modify kernel for something that kernel won't
> > > > > need to do anything immediately.
> > > >
> > > > I understood it as there would be explicit whitelist in kernel and new
> > > > GUIDs would be needed to add into whitelist, even those which do not
> > > > have kernel wmi driver.
> > > >
> > > > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > > > has one big problem. If kernel introduce new wmi driver for such GUID
> > > > then it block userspace to access it or at least would need to provide
> > > > audit filter and something would be probably filtered. It means that
> > > > some userspace applications which would use that GUIDs stops working
> > > > after upgrading to new kernel. And we can be in situation where *user*
> > > > need to decide: either use 3rd party userspace application from vendor
> > > > which provide some special settings for your laptop, or use kernel
> > > > module which provides standard rfkill/led/input class driver.
> > > >
> > >
> > > If this proposal goes forward it would sound like to me an audit filter
> > > would become a prerequisite for any new WMI kernel driver.  This is not
> > > a problem to me.
> >
> > Not for any wmi driver, only for those which would like to export wmi
> > device to userspace.
> 
> Correct.
> 
> >
> > > This audience recommends the way for users to configure the system but
> > > of course cannot stop users from doing what they decide to do.
> >
> > Of course, but in above hypothetical example, user is in situation where
> > is unable to use both 3rd vendor application and together kernel
> > rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
> > manual module loading) what want to use.
> >
> > But ideal solution is that both 3rd vendor application for firmware
> > settings and also rfkill kernel driver would work together without need
> > to rmmod/modprobe modules and without restarting 3rd vendor application.
> >
> > > We're all in agreement that the kernel should keep responsibility for some
> > > of these functionalities.
> > > If a new kernel WMI driver duplicates functionality that happens to find its
> > > way in userspace and the kernel audits that out yes the userspace
> > > application may start to  have less functionality, but better support
> > > would live in the kernel and the user would be better supported by
> > > the stack (for example could use standard rfkill userspace utilities).
> >
> 
> Pali has raised a very good point which I want to get some feedback from Linus,
> and perhaps tglx, hpa, and gregkh on. While Mario is expressing a very pragmatic
> approach which I certainly appreciate, we have a very strong position that we do
> not break userspace.
> 
> There have been exceptions for specific pseudo filesystems and such, but they
> are rare. We would need to document the WMI commitment from the kernel to
> userspace (e.g. any call may be filtered based on current Linux kernel WMI
> usage, which may change over time). This sounds troublesome... will give this
> some more thought.
> 

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

> > Ok. So it is acceptable solution/API/ABI for you & other Dell people?
> > Or is something more or different needed?
> >
> > Darren, I hope that I understood your proposal with explicit whitelist
> > correctly. And is there already another vendor which want to use wmi
> > userspace on linux?
> 
> It might be moot with Christoph's dynamic ID comment which I need to go review
> in detail. Putting that aside for a moment, what I intended was for the platform
> driver to whitelist GUIDs. But, that doesn't necessarily mean it has an explicit
> list. The platform driver could have a blacklist and then walk through all
> available GUIDs and export everything except those on the blacklist.

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

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

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

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

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

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

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

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

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

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

[toc] | [next] | [standalone]

#1636793

On Fri, May 05, 2017 at 09:55:46PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Darren Hart [mailto:dvhart@infradead.org]
> > Sent: Thursday, April 20, 2017 3:45 PM
> > To: Pali Rohár <pali.rohar@gmail.com>
> > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; rjw@rjwysocki.net;
> > luto@amacapital.net; len.brown@intel.com; corentin.chary@gmail.com;
> > luto@kernel.org; andriy.shevchenko@linux.intel.com; linux-
> > kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org; linux-
> > pm@vger.kernel.org
> > Subject: Re: RFC: WMI Enhancements
> > 
> > On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
> > > On Wednesday 19 April 2017 17:24:00 Mario.Limonciello@dell.com wrote:
> > > > > -----Original Message-----
> > > > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > > > Cc: dvhart@infradead.org; rjw@rjwysocki.net; luto@amacapital.net;
> > > > > len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org;
> > > > > andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> > > > > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> > > > > Subject: Re: RFC: WMI Enhancements
> > > > >
> > > > > On Wednesday 19 April 2017 18:29:53 Mario.Limonciello@dell.com wrote:
> > > > > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > > > > > will be exported to userspace after communication with vendor.
> > > > > >
> > > > > > What about GUID's not yet used by kernel drivers?  Would those
> > > > > > default to whitelist default to blacklist?  My preference would be
> > > > > > to default to whitelist. This allows new GUID's to be added later
> > > > > > without needing to modify kernel for something that kernel won't
> > > > > > need to do anything immediately.
> > > > >
> > > > > I understood it as there would be explicit whitelist in kernel and new
> > > > > GUIDs would be needed to add into whitelist, even those which do not
> > > > > have kernel wmi driver.
> > > > >
> > > > > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > > > > has one big problem. If kernel introduce new wmi driver for such GUID
> > > > > then it block userspace to access it or at least would need to provide
> > > > > audit filter and something would be probably filtered. It means that
> > > > > some userspace applications which would use that GUIDs stops working
> > > > > after upgrading to new kernel. And we can be in situation where *user*
> > > > > need to decide: either use 3rd party userspace application from vendor
> > > > > which provide some special settings for your laptop, or use kernel
> > > > > module which provides standard rfkill/led/input class driver.
> > > > >
> > > >
> > > > If this proposal goes forward it would sound like to me an audit filter
> > > > would become a prerequisite for any new WMI kernel driver.  This is not
> > > > a problem to me.
> > >
> > > Not for any wmi driver, only for those which would like to export wmi
> > > device to userspace.
> > 
> > Correct.
> > 
> > >
> > > > This audience recommends the way for users to configure the system but
> > > > of course cannot stop users from doing what they decide to do.
> > >
> > > Of course, but in above hypothetical example, user is in situation where
> > > is unable to use both 3rd vendor application and together kernel
> > > rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
> > > manual module loading) what want to use.
> > >
> > > But ideal solution is that both 3rd vendor application for firmware
> > > settings and also rfkill kernel driver would work together without need
> > > to rmmod/modprobe modules and without restarting 3rd vendor application.
> > >
> > > > We're all in agreement that the kernel should keep responsibility for some
> > > > of these functionalities.
> > > > If a new kernel WMI driver duplicates functionality that happens to find its
> > > > way in userspace and the kernel audits that out yes the userspace
> > > > application may start to  have less functionality, but better support
> > > > would live in the kernel and the user would be better supported by
> > > > the stack (for example could use standard rfkill userspace utilities).
> > >
> > 
> > Pali has raised a very good point which I want to get some feedback from Linus,
> > and perhaps tglx, hpa, and gregkh on. While Mario is expressing a very pragmatic
> > approach which I certainly appreciate, we have a very strong position that we do
> > not break userspace.
> > 
> > There have been exceptions for specific pseudo filesystems and such, but they
> > are rare. We would need to document the WMI commitment from the kernel to
> > userspace (e.g. any call may be filtered based on current Linux kernel WMI
> > usage, which may change over time). This sounds troublesome... will give this
> > some more thought.
> > 
> 
> There are other examples in the kernel of the same data accessible in multiple
> different methods that can cause inconsistencies too.

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

> 
> > > Ok. So it is acceptable solution/API/ABI for you & other Dell people?
> > > Or is something more or different needed?
> > >
> > > Darren, I hope that I understood your proposal with explicit whitelist
> > > correctly. And is there already another vendor which want to use wmi
> > > userspace on linux?
> > 
> > It might be moot with Christoph's dynamic ID comment which I need to go review
> > in detail. Putting that aside for a moment, what I intended was for the platform
> > driver to whitelist GUIDs. But, that doesn't necessarily mean it has an explicit
> > list. The platform driver could have a blacklist and then walk through all
> > available GUIDs and export everything except those on the blacklist.
> 
> To get this started can you re-review Andy's platform/wmi tree and merge in some
> of his bus work?  Regardless of the outcome of the access to userspace and dynamic
> binding this is a good direction for WMI support in platform/drivers/x86 to get started.

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

> 
> > 
> > Now with Christoph's idea, we may be able to maintain a blacklist of GUIDs and a
> > whitelist of platforms which CAN export WMI, but not export any until userspace
> > requests a specific GUID be exported at which point it is checked against the
> > blacklist and then exported accordingly, at which point the WMI method filters
> > handle the rest.
> > 
> 
> I've been studying more about how this access to WMI BIOS functions on Windows
> works this week and uncovered what I see as another set of related questions around
> commitment to manageability access from the OS with this potential userspace layer.
> 
> On Windows what happens is the MOF data (same stuff exposed by Andy's wmi-mof)
> is imported into the WMI namespace.  This allows any tools to know exactly how
> to interact with the various GUID's associated to the ASL methods.  The format of the
> data and the arguments supported are encoded directly in that MOF data.
> 
> This means that standard WBEM tools are able to interact directly with these methods
> based upon exposed objects.  BIOS manufacturer can expose say all BIOS settings that 
> are integer to a GUID for interacting with integer settings and those would get loaded 
> into the WMI namespace.  When someone uses a WBEM tool to modify that object
> the data is properly formatted into the correct arguments for an integer and then run 
> through the ASL.  Another GUID might be made for strings and another for specially
> crafted lists (like a boot order).  The important part is that all settings are discoverable
> and no extra tools are needed to administer a box.  It can all be done from things like 
> PowerShell or wmic.

Ah, that's good insight, thank you.

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

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

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

Definitely *not* a perfect world :-)

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

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

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

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

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

-- 
Darren Hart
VMware Open Source Technology Center

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

#1636796

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Friday, May 5, 2017 6:45 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: pali.rohar@gmail.com; rjw@rjwysocki.net; luto@amacapital.net;
> len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org;
> andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Fri, May 05, 2017 at 09:55:46PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Darren Hart [mailto:dvhart@infradead.org]
> > > Sent: Thursday, April 20, 2017 3:45 PM
> > > To: Pali Rohár <pali.rohar@gmail.com>
> > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; rjw@rjwysocki.net;
> > > luto@amacapital.net; len.brown@intel.com; corentin.chary@gmail.com;
> > > luto@kernel.org; andriy.shevchenko@linux.intel.com; linux-
> > > kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org; linux-
> > > pm@vger.kernel.org
> > > Subject: Re: RFC: WMI Enhancements
> > >
> > > On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
> > > > On Wednesday 19 April 2017 17:24:00 Mario.Limonciello@dell.com wrote:
> > > > > > -----Original Message-----
> > > > > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > > > > Cc: dvhart@infradead.org; rjw@rjwysocki.net; luto@amacapital.net;
> > > > > > len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org;
> > > > > > andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org;
> platform-
> > > > > > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> > > > > > Subject: Re: RFC: WMI Enhancements
> > > > > >
> > > > > > On Wednesday 19 April 2017 18:29:53 Mario.Limonciello@dell.com
> wrote:
> > > > > > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > > > > > > will be exported to userspace after communication with vendor.
> > > > > > >
> > > > > > > What about GUID's not yet used by kernel drivers?  Would those
> > > > > > > default to whitelist default to blacklist?  My preference would be
> > > > > > > to default to whitelist. This allows new GUID's to be added later
> > > > > > > without needing to modify kernel for something that kernel won't
> > > > > > > need to do anything immediately.
> > > > > >
> > > > > > I understood it as there would be explicit whitelist in kernel and new
> > > > > > GUIDs would be needed to add into whitelist, even those which do not
> > > > > > have kernel wmi driver.
> > > > > >
> > > > > > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > > > > > has one big problem. If kernel introduce new wmi driver for such GUID
> > > > > > then it block userspace to access it or at least would need to provide
> > > > > > audit filter and something would be probably filtered. It means that
> > > > > > some userspace applications which would use that GUIDs stops working
> > > > > > after upgrading to new kernel. And we can be in situation where *user*
> > > > > > need to decide: either use 3rd party userspace application from vendor
> > > > > > which provide some special settings for your laptop, or use kernel
> > > > > > module which provides standard rfkill/led/input class driver.
> > > > > >
> > > > >
> > > > > If this proposal goes forward it would sound like to me an audit filter
> > > > > would become a prerequisite for any new WMI kernel driver.  This is not
> > > > > a problem to me.
> > > >
> > > > Not for any wmi driver, only for those which would like to export wmi
> > > > device to userspace.
> > >
> > > Correct.
> > >
> > > >
> > > > > This audience recommends the way for users to configure the system but
> > > > > of course cannot stop users from doing what they decide to do.
> > > >
> > > > Of course, but in above hypothetical example, user is in situation where
> > > > is unable to use both 3rd vendor application and together kernel
> > > > rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
> > > > manual module loading) what want to use.
> > > >
> > > > But ideal solution is that both 3rd vendor application for firmware
> > > > settings and also rfkill kernel driver would work together without need
> > > > to rmmod/modprobe modules and without restarting 3rd vendor application.
> > > >
> > > > > We're all in agreement that the kernel should keep responsibility for some
> > > > > of these functionalities.
> > > > > If a new kernel WMI driver duplicates functionality that happens to find its
> > > > > way in userspace and the kernel audits that out yes the userspace
> > > > > application may start to  have less functionality, but better support
> > > > > would live in the kernel and the user would be better supported by
> > > > > the stack (for example could use standard rfkill userspace utilities).
> > > >
> > >
> > > Pali has raised a very good point which I want to get some feedback from Linus,
> > > and perhaps tglx, hpa, and gregkh on. While Mario is expressing a very
> pragmatic
> > > approach which I certainly appreciate, we have a very strong position that we
> do
> > > not break userspace.
> > >
> > > There have been exceptions for specific pseudo filesystems and such, but they
> > > are rare. We would need to document the WMI commitment from the kernel to
> > > userspace (e.g. any call may be filtered based on current Linux kernel WMI
> > > usage, which may change over time). This sounds troublesome... will give this
> > > some more thought.
> > >
> >
> > There are other examples in the kernel of the same data accessible in multiple
> > different methods that can cause inconsistencies too.
> 
> Something that occurred to me today is we could include in the API of the WMI
> device the potential return of -EBUSY anytime the kernel decides it can't safely
> service a call. This would avoid *changing* the API exposed to userspace, but it
> could change the behavior and availability of certain methods.
> 
> >
> > > > Ok. So it is acceptable solution/API/ABI for you & other Dell people?
> > > > Or is something more or different needed?
> > > >
> > > > Darren, I hope that I understood your proposal with explicit whitelist
> > > > correctly. And is there already another vendor which want to use wmi
> > > > userspace on linux?
> > >
> > > It might be moot with Christoph's dynamic ID comment which I need to go
> review
> > > in detail. Putting that aside for a moment, what I intended was for the platform
> > > driver to whitelist GUIDs. But, that doesn't necessarily mean it has an explicit
> > > list. The platform driver could have a blacklist and then walk through all
> > > available GUIDs and export everything except those on the blacklist.
> >
> > To get this started can you re-review Andy's platform/wmi tree and merge in
> some
> > of his bus work?  Regardless of the outcome of the access to userspace and
> dynamic
> > binding this is a good direction for WMI support in platform/drivers/x86 to get
> started.
> 
> Yes, this is already queued up for next week, and will be targeted at the 4.13
> merge window.
> 

OK great.

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

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

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

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

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

OK thanks.

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

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

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

#1636801

On Fri, May 5, 2017 at 5:51 PM,  <Mario.Limonciello@dell.com> wrote:
>> -----Original Message-----
>> From: Darren Hart [mailto:dvhart@infradead.org]
>> Sent: Friday, May 5, 2017 6:45 PM
>> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
>> Cc: pali.rohar@gmail.com; rjw@rjwysocki.net; luto@amacapital.net;
>> len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org;
>> andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform-
>> driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
>> Subject: Re: RFC: WMI Enhancements


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

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

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

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

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

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

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

#1637513

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

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

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

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

It's a start.

-- 
Darren Hart
VMware Open Source Technology Center

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

#1637522

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

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

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

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

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

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

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

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

#1637533

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

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

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

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

-- 
Darren Hart
VMware Open Source Technology Center

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

#1637541

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

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

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

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

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


-- 
With Best Regards,
Andy Shevchenko

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

#1637645

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

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

Thanks!  That was a very interesting read.

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

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

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

#1637647

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

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

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

-- 
Darren Hart
VMware Open Source Technology Center

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

#1637659

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

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

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

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

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

Should be continued to use in new designs.

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

#1637543

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

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

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

Thanks,

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

#1637601

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

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

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

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

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

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

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

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

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

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

#1637667

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, May 8, 2017 12:18 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; rjw@rjwysocki.net; luto@amacapital.net;
> len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org;
> andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Friday 05 May 2017 23:55:46 Mario.Limonciello@dell.com wrote:
> > Unfortunately the MOF data that comes out of wmi-mof is so called
> > "Binary MOF" which has been pre-compiled to an intermediate format
> > with mofcomp.exe on Windows. The format of binary MOF is not
> > documented and the only known way to get text mof back out is by
> > using mofcomp.exe with some esoteric arguments.
> >
> > mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
> > binary_mof_file
> 
> Looks like that binary MOF file has "well-known" file extension .bmf.
> File itself starts with magic hader "FOMB" which is in reverse BMOF
> (binary mof). But I was not able to find any specification nor any other
> details. As this binary format is dated back to Win9x I guess data would
> compressed by some old MS compression algorithm (CAB?).

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

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

On a compiled Dell binary MOF the next are:

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

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

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

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

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

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

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

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

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

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

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

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

#1637723

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

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

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

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

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

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

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

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

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

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

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

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

#1637731

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

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

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

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

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

#1637766

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

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

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

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

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

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

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

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

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

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

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

#1637805

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

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

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

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

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

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

#1637933

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

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

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

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

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

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

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

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

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

#1638329

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Tuesday, May 9, 2017 2:29 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; rjw@rjwysocki.net; luto@amacapital.net;
> len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org;
> andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Tuesday 09 May 2017 01:10:54 Mario.Limonciello@dell.com wrote:
> > >
> > > I found dmsdos implementation of that DS compression at:
> > > http://cmp.felk.cvut.cz/~pisa/dmsdos
> > >
> > > Then took relevant decompression code and it really decompressed that
> > > binary MOF WMI buffer. But still decompressed format is binary, but I
> > > now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again
> > > "FOMB" magic header.
> >
> > Well that's great.  Is it possible that this compression is used for every time
> > a class was declared?
> 
> Looks like not. That decompressed output seems to be not compressed
> anymore. Just use same magic header.
Actually it looks like a new magic header to me after decompressed.

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

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

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

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

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web