RE: RFC: WMI Enhancements

From: <Mario.Limonciello@dell.com>
To: <pali.rohar@gmail.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
Date: Mon, 8 May 2017 19:21:45 +0000	[thread overview]
Message-ID: <c073b5f67d1e495481613711753356ba@ausx13mpc120.AMER.DELL.COM> (raw)
In-Reply-To: <201705081917.34242@pali>

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