Re: RFC: WMI Enhancements

[Pali Rohár]

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

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

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

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

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

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

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


signature.asc
Description: This is a digitally signed message part.

Re: RFC: WMI Enhancements

[Pali Rohár]

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

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

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

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

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

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

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


signature.asc
Description: This is a digitally signed message part.

Re: RFC: WMI Enhancements

[Andy Shevchenko]

On Tue, May 9, 2017 at 10:16 PM,   wrote:


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

>> 0x1554

This one looks like offset (or size 5460)

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

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

0x15d8

Again, looks like offset (or size).

0x04ed



-- 
With Best Regards,
Andy Shevchenko

Re: RFC: WMI Enhancements

[Andy Shevchenko]

On Tue, May 9, 2017 at 10:16 PM,   wrote:


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

>> 0x1554

This one looks like offset (or size 5460)

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

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

0x15d8

Again, looks like offset (or size).

0x04ed



-- 
With Best Regards,
Andy Shevchenko

Re: RFC: WMI Enhancements

[Pali Rohár]

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

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

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

So magic is only FOMB.

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


signature.asc
Description: This is a digitally signed message part.

Re: RFC: WMI Enhancements

[Pali Rohár]

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

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

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

So magic is only FOMB.

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


signature.asc
Description: This is a digitally signed message part.

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

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

> --
> With Best Regards,
> Andy Shevchenko

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

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

> --
> With Best Regards,
> Andy Shevchenko

Re: RFC: WMI Enhancements

[Andy Shevchenko]

On Tue, May 9, 2017 at 9:10 PM,   wrote:

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

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

0x1554
0x0001
0x0001

from the above dump.

-- 
With Best Regards,
Andy Shevchenko

Re: RFC: WMI Enhancements

[Andy Shevchenko]

On Tue, May 9, 2017 at 9:10 PM,   wrote:

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

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

0x1554
0x0001
0x0001

from the above dump.

-- 
With Best Regards,
Andy Shevchenko

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Tuesday, May 9, 2017 2:29 AM
> To: Limonciello, Mario <mario_limoncie...@dell.com>
> Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Tuesday 09 May 2017 01:10:54 mario.limoncie...@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).

0150  08 00 00 00 00 00 00 00  10 00 00 00 4c 00 6f 00  |L.o.|
0160  63 00 61 00 6c 00 65 00  00 00 00 00 4d 00 53 00  |c.a.l.e.M.S.|
0170  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.

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Tuesday, May 9, 2017 2:29 AM
> To: Limonciello, Mario 
> Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Tuesday 09 May 2017 01:10:54 mario.limoncie...@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).

0150  08 00 00 00 00 00 00 00  10 00 00 00 4c 00 6f 00  |L.o.|
0160  63 00 61 00 6c 00 65 00  00 00 00 00 4d 00 53 00  |c.a.l.e.M.S.|
0170  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.

Re: RFC: WMI Enhancements

[Pali Rohár]

On Tuesday 09 May 2017 01:10:54 mario.limoncie...@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.ro...@gmail.com

Re: RFC: WMI Enhancements

[Pali Rohár]

On Tuesday 09 May 2017 01:10:54 mario.limoncie...@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.ro...@gmail.com

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

Re: RFC: WMI Enhancements

[Pali Rohár]

On Monday 08 May 2017 23:18:11 mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > Sent: Monday, May 8, 2017 4:00 PM
> > To: Limonciello, Mario <mario_limoncie...@dell.com>
> > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> > platform- driver-...@vger.kernel.org; linux...@vger.kernel.org
> > Subject: Re: RFC: WMI Enhancements
> > 
> > On Monday 08 May 2017 21:21:45 mario.limoncie...@dell.com wrote:
> > > > -Original Message-
> > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > Sent: Monday, May 8, 2017 12:18 PM
> > > > To: Limonciello, Mario <mario_limoncie...@dell.com>
> > > > Cc: dvh...@infradead.org; r...@rjwysocki.net;
> > > > l...@amacapital.net; len.br...@intel.com;
> > > > corentin.ch...@gmail.com; l...@kernel.org;
> > > > andriy.shevche...@linux.intel.com;
> > > > linux-kernel@vger.kernel.org; platform-
> > > > driver-...@vger.kernel.org; linux...@vger.kernel.org Subject:
> > > > Re: RFC: WMI Enhancements
> > > > 
> > > > On Friday 05 May 2017 23:55:46 mario.limoncie...@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 

Re: RFC: WMI Enhancements

[Pali Rohár]

On Monday 08 May 2017 23:18:11 mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > Sent: Monday, May 8, 2017 4:00 PM
> > To: Limonciello, Mario 
> > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> > platform- driver-...@vger.kernel.org; linux...@vger.kernel.org
> > Subject: Re: RFC: WMI Enhancements
> > 
> > On Monday 08 May 2017 21:21:45 mario.limoncie...@dell.com wrote:
> > > > -Original Message-
> > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > Sent: Monday, May 8, 2017 12:18 PM
> > > > To: Limonciello, Mario 
> > > > Cc: dvh...@infradead.org; r...@rjwysocki.net;
> > > > l...@amacapital.net; len.br...@intel.com;
> > > > corentin.ch...@gmail.com; l...@kernel.org;
> > > > andriy.shevche...@linux.intel.com;
> > > > linux-kernel@vger.kernel.org; platform-
> > > > driver-...@vger.kernel.org; linux...@vger.kernel.org Subject:
> > > > Re: RFC: WMI Enhancements
> > > > 
> > > > On Friday 05 May 2017 23:55:46 mario.limoncie...@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 

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Monday, May 8, 2017 4:00 PM
> To: Limonciello, Mario <mario_limoncie...@dell.com>
> Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Monday 08 May 2017 21:21:45 mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > Sent: Monday, May 8, 2017 12:18 PM
> > > To: Limonciello, Mario <mario_limoncie...@dell.com>
> > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> > > platform- driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > Subject: Re: RFC: WMI Enhancements
> > >
> > > On Friday 05 May 2017 23:55:46 mario.limoncie...@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.

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Monday, May 8, 2017 4:00 PM
> To: Limonciello, Mario 
> Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Monday 08 May 2017 21:21:45 mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > Sent: Monday, May 8, 2017 12:18 PM
> > > To: Limonciello, Mario 
> > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> > > platform- driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > Subject: Re: RFC: WMI Enhancements
> > >
> > > On Friday 05 May 2017 23:55:46 mario.limoncie...@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.

Re: RFC: WMI Enhancements

[Pali Rohár]

On Monday 08 May 2017 21:21:45 mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > Sent: Monday, May 8, 2017 12:18 PM
> > To: Limonciello, Mario <mario_limoncie...@dell.com>
> > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> > platform- driver-...@vger.kernel.org; linux...@vger.kernel.org
> > Subject: Re: RFC: WMI Enhancements
> > 
> > On Friday 05 May 2017 23:55:46 mario.limoncie...@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.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: RFC: WMI Enhancements

[Pali Rohár]

On Monday 08 May 2017 21:21:45 mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > Sent: Monday, May 8, 2017 12:18 PM
> > To: Limonciello, Mario 
> > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> > platform- driver-...@vger.kernel.org; linux...@vger.kernel.org
> > Subject: Re: RFC: WMI Enhancements
> > 
> > On Friday 05 May 2017 23:55:46 mario.limoncie...@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.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Monday, May 8, 2017 12:18 PM
> To: Limonciello, Mario <mario_limoncie...@dell.com>
> Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Friday 05 May 2017 23:55:46 mario.limoncie...@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.

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Monday, May 8, 2017 12:18 PM
> To: Limonciello, Mario 
> Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Friday 05 May 2017 23:55:46 mario.limoncie...@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.

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Monday, May 8, 2017 2:09 PM
> To: Limonciello, Mario <mario_limoncie...@dell.com>
> Cc: a.boko...@gmail.com; andy.shevche...@gmail.com; l...@kernel.org;
> pali.ro...@gmail.com; r...@rjwysocki.net; len.br...@intel.com;
> corentin.ch...@gmail.com; andriy.shevche...@linux.intel.com; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> p...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Mon, May 08, 2017 at 06:26:53PM +, mario.limoncie...@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.

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Monday, May 8, 2017 2:09 PM
> To: Limonciello, Mario 
> Cc: a.boko...@gmail.com; andy.shevche...@gmail.com; l...@kernel.org;
> pali.ro...@gmail.com; r...@rjwysocki.net; len.br...@intel.com;
> corentin.ch...@gmail.com; andriy.shevche...@linux.intel.com; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> p...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Mon, May 08, 2017 at 06:26:53PM +, mario.limoncie...@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.

Re: RFC: WMI Enhancements

[Darren Hart]

On Mon, May 08, 2017 at 06:26:53PM +, mario.limoncie...@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

Re: RFC: WMI Enhancements

[Darren Hart]

On Mon, May 08, 2017 at 06:26:53PM +, mario.limoncie...@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

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

Re: RFC: WMI Enhancements

[Pali Rohár]

On Friday 05 May 2017 23:55:46 mario.limoncie...@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.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: RFC: WMI Enhancements

[Pali Rohár]

On Friday 05 May 2017 23:55:46 mario.limoncie...@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.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: RFC: WMI Enhancements

[Andy Shevchenko]

+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  wrote:
> On Mon, May 08, 2017 at 03:36:31PM +, mario.limoncie...@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

Re: RFC: WMI Enhancements

[Andy Shevchenko]

+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  wrote:
> On Mon, May 08, 2017 at 03:36:31PM +, mario.limoncie...@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

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Monday, May 8, 2017 10:47 AM
> To: Limonciello, Mario <mario_limoncie...@dell.com>
> Cc: l...@kernel.org; pali.ro...@gmail.com; r...@rjwysocki.net;
> len.br...@intel.com; corentin.ch...@gmail.com;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Mon, May 08, 2017 at 03:36:31PM +, mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Darren Hart [mailto:dvh...@infradead.org]
> > > Sent: Monday, May 8, 2017 10:29 AM
> > > To: Andy Lutomirski <l...@kernel.org>
> > > Cc: Limonciello, Mario <mario_limoncie...@dell.com>; Pali Rohár
> > > <pali.ro...@gmail.com>; Rafael J. Wysocki <r...@rjwysocki.net>; Len Brown
> > > <len.br...@intel.com>; Corentin Chary <corentin.ch...@gmail.com>; Andy
> > > Shevchenko <andriy.shevche...@linux.intel.com>; linux-
> ker...@vger.kernel.org;
> > > platform-driver-...@vger.kernel.org; linux...@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.limoncie...@dell.com> wrote:
> > > > >> -Original Message-
> > > > >> From: Darren Hart [mailto:dvh...@infradead.org]
> > > > >> Sent: Friday, May 5, 2017 6:45 PM
> > > > >> To: Limonciello, Mario <mario_limoncie...@dell.com>
> > > > >> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> > > > >> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > >> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> platform-
> > > > >> driver-...@vger.kernel.org; linux...@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,

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Monday, May 8, 2017 10:47 AM
> To: Limonciello, Mario 
> Cc: l...@kernel.org; pali.ro...@gmail.com; r...@rjwysocki.net;
> len.br...@intel.com; corentin.ch...@gmail.com;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Mon, May 08, 2017 at 03:36:31PM +, mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Darren Hart [mailto:dvh...@infradead.org]
> > > Sent: Monday, May 8, 2017 10:29 AM
> > > To: Andy Lutomirski 
> > > Cc: Limonciello, Mario ; Pali Rohár
> > > ; Rafael J. Wysocki ; Len Brown
> > > ; Corentin Chary ; Andy
> > > Shevchenko ; linux-
> ker...@vger.kernel.org;
> > > platform-driver-...@vger.kernel.org; linux...@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,   wrote:
> > > > >> -Original Message-
> > > > >> From: Darren Hart [mailto:dvh...@infradead.org]
> > > > >> Sent: Friday, May 5, 2017 6:45 PM
> > > > >> To: Limonciello, Mario 
> > > > >> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> > > > >> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > >> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> platform-
> > > > >> driver-...@vger.kernel.org; linux...@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,

Re: RFC: WMI Enhancements

[Darren Hart]

On Mon, May 08, 2017 at 03:36:31PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Monday, May 8, 2017 10:29 AM
> > To: Andy Lutomirski <l...@kernel.org>
> > Cc: Limonciello, Mario <mario_limoncie...@dell.com>; Pali Rohár
> > <pali.ro...@gmail.com>; Rafael J. Wysocki <r...@rjwysocki.net>; Len Brown
> > <len.br...@intel.com>; Corentin Chary <corentin.ch...@gmail.com>; Andy
> > Shevchenko <andriy.shevche...@linux.intel.com>; 
> > linux-kernel@vger.kernel.org;
> > platform-driver-...@vger.kernel.org; linux...@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.limoncie...@dell.com> wrote:
> > > >> -Original Message-
> > > >> From: Darren Hart [mailto:dvh...@infradead.org]
> > > >> Sent: Friday, May 5, 2017 6:45 PM
> > > >> To: Limonciello, Mario <mario_limoncie...@dell.com>
> > > >> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> > > >> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > >> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; 
> > > >> platform-
> > > >> driver-...@vger.kernel.org; linux...@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

Re: RFC: WMI Enhancements

[Darren Hart]

On Mon, May 08, 2017 at 03:36:31PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Monday, May 8, 2017 10:29 AM
> > To: Andy Lutomirski 
> > Cc: Limonciello, Mario ; Pali Rohár
> > ; Rafael J. Wysocki ; Len Brown
> > ; Corentin Chary ; Andy
> > Shevchenko ; 
> > linux-kernel@vger.kernel.org;
> > platform-driver-...@vger.kernel.org; linux...@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,   wrote:
> > > >> -Original Message-
> > > >> From: Darren Hart [mailto:dvh...@infradead.org]
> > > >> Sent: Friday, May 5, 2017 6:45 PM
> > > >> To: Limonciello, Mario 
> > > >> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> > > >> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > >> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; 
> > > >> platform-
> > > >> driver-...@vger.kernel.org; linux...@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

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Monday, May 8, 2017 10:29 AM
> To: Andy Lutomirski <l...@kernel.org>
> Cc: Limonciello, Mario <mario_limoncie...@dell.com>; Pali Rohár
> <pali.ro...@gmail.com>; Rafael J. Wysocki <r...@rjwysocki.net>; Len Brown
> <len.br...@intel.com>; Corentin Chary <corentin.ch...@gmail.com>; Andy
> Shevchenko <andriy.shevche...@linux.intel.com>; linux-kernel@vger.kernel.org;
> platform-driver-...@vger.kernel.org; linux...@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.limoncie...@dell.com> wrote:
> > >> -Original Message-
> > >> From: Darren Hart [mailto:dvh...@infradead.org]
> > >> Sent: Friday, May 5, 2017 6:45 PM
> > >> To: Limonciello, Mario <mario_limoncie...@dell.com>
> > >> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> > >> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > >> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; 
> > >> platform-
> > >> driver-...@vger.kernel.org; linux...@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.

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Monday, May 8, 2017 10:29 AM
> To: Andy Lutomirski 
> Cc: Limonciello, Mario ; Pali Rohár
> ; Rafael J. Wysocki ; Len Brown
> ; Corentin Chary ; Andy
> Shevchenko ; linux-kernel@vger.kernel.org;
> platform-driver-...@vger.kernel.org; linux...@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,   wrote:
> > >> -Original Message-
> > >> From: Darren Hart [mailto:dvh...@infradead.org]
> > >> Sent: Friday, May 5, 2017 6:45 PM
> > >> To: Limonciello, Mario 
> > >> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> > >> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > >> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; 
> > >> platform-
> > >> driver-...@vger.kernel.org; linux...@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.

Re: RFC: WMI Enhancements

[Darren Hart]

On Fri, May 05, 2017 at 06:25:08PM -0700, Andy Lutomirski wrote:
> On Fri, May 5, 2017 at 5:51 PM,  <mario.limoncie...@dell.com> wrote:
> >> -Original Message-
> >> From: Darren Hart [mailto:dvh...@infradead.org]
> >> Sent: Friday, May 5, 2017 6:45 PM
> >> To: Limonciello, Mario <mario_limoncie...@dell.com>
> >> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> >> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> >> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> >> driver-...@vger.kernel.org; linux...@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

Re: RFC: WMI Enhancements

[Darren Hart]

On Fri, May 05, 2017 at 06:25:08PM -0700, Andy Lutomirski wrote:
> On Fri, May 5, 2017 at 5:51 PM,   wrote:
> >> -Original Message-
> >> From: Darren Hart [mailto:dvh...@infradead.org]
> >> Sent: Friday, May 5, 2017 6:45 PM
> >> To: Limonciello, Mario 
> >> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> >> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> >> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> >> driver-...@vger.kernel.org; linux...@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

Re: RFC: WMI Enhancements

[Andy Lutomirski]

On Fri, May 5, 2017 at 5:51 PM,  <mario.limoncie...@dell.com> wrote:
>> -Original Message-
>> From: Darren Hart [mailto:dvh...@infradead.org]
>> Sent: Friday, May 5, 2017 6:45 PM
>> To: Limonciello, Mario <mario_limoncie...@dell.com>
>> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
>> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
>> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
>> driver-...@vger.kernel.org; linux...@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.

Re: RFC: WMI Enhancements

[Andy Lutomirski]

On Fri, May 5, 2017 at 5:51 PM,   wrote:
>> -Original Message-
>> From: Darren Hart [mailto:dvh...@infradead.org]
>> Sent: Friday, May 5, 2017 6:45 PM
>> To: Limonciello, Mario 
>> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
>> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
>> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
>> driver-...@vger.kernel.org; linux...@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.

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, May 5, 2017 6:45 PM
> To: Limonciello, Mario <mario_limoncie...@dell.com>
> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Darren Hart [mailto:dvh...@infradead.org]
> > > Sent: Thursday, April 20, 2017 3:45 PM
> > > To: Pali Rohár <pali.ro...@gmail.com>
> > > Cc: Limonciello, Mario <mario_limoncie...@dell.com>; r...@rjwysocki.net;
> > > l...@amacapital.net; len.br...@intel.com; corentin.ch...@gmail.com;
> > > l...@kernel.org; andriy.shevche...@linux.intel.com; linux-
> > > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> > > p...@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.limoncie...@dell.com wrote:
> > > > > > -Original Message-
> > > > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > > > To: Limonciello, Mario <mario_limoncie...@dell.com>
> > > > > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > > > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> platform-
> > > > > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > > > > Subject: Re: RFC: WMI Enhancements
> > > > > >
> > > > > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@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.
> > >
>

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, May 5, 2017 6:45 PM
> To: Limonciello, Mario 
> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Darren Hart [mailto:dvh...@infradead.org]
> > > Sent: Thursday, April 20, 2017 3:45 PM
> > > To: Pali Rohár 
> > > Cc: Limonciello, Mario ; r...@rjwysocki.net;
> > > l...@amacapital.net; len.br...@intel.com; corentin.ch...@gmail.com;
> > > l...@kernel.org; andriy.shevche...@linux.intel.com; linux-
> > > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> > > p...@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.limoncie...@dell.com wrote:
> > > > > > -Original Message-
> > > > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > > > To: Limonciello, Mario 
> > > > > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > > > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> platform-
> > > > > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > > > > Subject: Re: RFC: WMI Enhancements
> > > > > >
> > > > > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@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
> > > > > o

Re: RFC: WMI Enhancements

[Darren Hart]

On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Thursday, April 20, 2017 3:45 PM
> > To: Pali Rohár <pali.ro...@gmail.com>
> > Cc: Limonciello, Mario <mario_limoncie...@dell.com>; r...@rjwysocki.net;
> > l...@amacapital.net; len.br...@intel.com; corentin.ch...@gmail.com;
> > l...@kernel.org; andriy.shevche...@linux.intel.com; linux-
> > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> > p...@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.limoncie...@dell.com wrote:
> > > > > -Original Message-
> > > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > > To: Limonciello, Mario <mario_limoncie...@dell.com>
> > > > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; 
> > > > > platform-
> > > > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > > > Subject: Re: RFC: WMI Enhancements
> > > > >
> > > > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@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 functi

Re: RFC: WMI Enhancements

[Darren Hart]

On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Thursday, April 20, 2017 3:45 PM
> > To: Pali Rohár 
> > Cc: Limonciello, Mario ; r...@rjwysocki.net;
> > l...@amacapital.net; len.br...@intel.com; corentin.ch...@gmail.com;
> > l...@kernel.org; andriy.shevche...@linux.intel.com; linux-
> > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> > p...@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.limoncie...@dell.com wrote:
> > > > > -Original Message-
> > > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > > To: Limonciello, Mario 
> > > > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; 
> > > > > platform-
> > > > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > > > Subject: Re: RFC: WMI Enhancements
> > > > >
> > > > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@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 userspac

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Thursday, April 20, 2017 3:45 PM
> To: Pali Rohár <pali.ro...@gmail.com>
> Cc: Limonciello, Mario <mario_limoncie...@dell.com>; r...@rjwysocki.net;
> l...@amacapital.net; len.br...@intel.com; corentin.ch...@gmail.com;
> l...@kernel.org; andriy.shevche...@linux.intel.com; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> p...@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.limoncie...@dell.com wrote:
> > > > -Original Message-
> > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > To: Limonciello, Mario <mario_limoncie...@dell.com>
> > > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; 
> > > > platform-
> > > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > > Subject: Re: RFC: WMI Enhancements
> > > >
> > > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@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, h

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Thursday, April 20, 2017 3:45 PM
> To: Pali Rohár 
> Cc: Limonciello, Mario ; r...@rjwysocki.net;
> l...@amacapital.net; len.br...@intel.com; corentin.ch...@gmail.com;
> l...@kernel.org; andriy.shevche...@linux.intel.com; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> p...@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.limoncie...@dell.com wrote:
> > > > -Original Message-
> > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > To: Limonciello, Mario 
> > > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; 
> > > > platform-
> > > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > > Subject: Re: RFC: WMI Enhancements
> > > >
> > > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@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 cert

Re: RFC: WMI Enhancements

[Darren Hart]

On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
> On Wednesday 19 April 2017 17:24:00 mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > To: Limonciello, Mario <mario_limoncie...@dell.com>
> > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > Subject: Re: RFC: WMI Enhancements
> > > 
> > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com wrote:
> > > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > > > will be exported to userspace after communication with vendor.
> > > >
> > > > What about GUID's not yet used by kernel drivers?  Would those
> > > > default to whitelist default to blacklist?  My preference would be
> > > > to default to whitelist. This allows new GUID's to be added later
> > > > without needing to modify kernel for something that kernel won't
> > > > need to do anything immediately.
> > > 
> > > I understood it as there would be explicit whitelist in kernel and new
> > > GUIDs would be needed to add into whitelist, even those which do not
> > > have kernel wmi driver.
> > > 
> > > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > > has one big problem. If kernel introduce new wmi driver for such GUID
> > > then it block userspace to access it or at least would need to provide
> > > audit filter and something would be probably filtered. It means that
> > > some userspace applications which would use that GUIDs stops working
> > > after upgrading to new kernel. And we can be in situation where *user*
> > > need to decide: either use 3rd party userspace application from vendor
> > > which provide some special settings for your laptop, or use kernel
> > > module which provides standard rfkill/led/input class driver.
> > > 
> > 
> > If this proposal goes forward it would sound like to me an audit filter
> > would become a prerequisite for any new WMI kernel driver.  This is not
> > a problem to me.
> 
> Not for any wmi driver, only for those which would like to export wmi
> device to userspace.

Correct.

> 
> > This audience recommends the way for users to configure the system but 
> > of course cannot stop users from doing what they decide to do.  
> 
> Of course, but in above hypothetical example, user is in situation where
> is unable to use both 3rd vendor application and together kernel
> rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
> manual module loading) what want to use.
> 
> But ideal solution is that both 3rd vendor application for firmware
> settings and also rfkill kernel driver would work together without need
> to rmmod/modprobe modules and without restarting 3rd vendor application.
> 
> > We're all in agreement that the kernel should keep responsibility for some
> > of these functionalities.
> > If a new kernel WMI driver duplicates functionality that happens to find 
> > its 
> > way in userspace and the kernel audits that out yes the userspace 
> > application may start to  have less functionality, but better support 
> > would live in the kernel and the user would be better supported by 
> > the stack (for example could use standard rfkill userspace utilities).
> 

Pali has raised a very good point which I want to get some feedback from Linus,
and perhaps tglx, hpa, and gregkh on. While Mario is expressing a very pragmatic
approach which I certainly appreciate, we have a very strong position that we do
not break userspace.

There have been exceptions for specific pseudo filesystems and such, but they
are rare. We would need to document the WMI commitment from the kernel to
userspace (e.g. any call may be filtered based on current Linux kernel WMI
usage, which may change over time). This sounds troublesome... will give this
some more thought.

> Ok. So it is acceptable solution/API/ABI for you & other Dell people?
> Or is something more or different needed?
> 
> Darren, I hope that I understood your proposal with explicit whitelist
> correctly. And is there already another vendor which want to use wmi
> userspace on linux?

It might be moot with Christoph's dynamic ID comment which I need to go review
in detail. Putting that

Re: RFC: WMI Enhancements

[Darren Hart]

On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
> On Wednesday 19 April 2017 17:24:00 mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > To: Limonciello, Mario 
> > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > Subject: Re: RFC: WMI Enhancements
> > > 
> > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com wrote:
> > > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > > > will be exported to userspace after communication with vendor.
> > > >
> > > > What about GUID's not yet used by kernel drivers?  Would those
> > > > default to whitelist default to blacklist?  My preference would be
> > > > to default to whitelist. This allows new GUID's to be added later
> > > > without needing to modify kernel for something that kernel won't
> > > > need to do anything immediately.
> > > 
> > > I understood it as there would be explicit whitelist in kernel and new
> > > GUIDs would be needed to add into whitelist, even those which do not
> > > have kernel wmi driver.
> > > 
> > > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > > has one big problem. If kernel introduce new wmi driver for such GUID
> > > then it block userspace to access it or at least would need to provide
> > > audit filter and something would be probably filtered. It means that
> > > some userspace applications which would use that GUIDs stops working
> > > after upgrading to new kernel. And we can be in situation where *user*
> > > need to decide: either use 3rd party userspace application from vendor
> > > which provide some special settings for your laptop, or use kernel
> > > module which provides standard rfkill/led/input class driver.
> > > 
> > 
> > If this proposal goes forward it would sound like to me an audit filter
> > would become a prerequisite for any new WMI kernel driver.  This is not
> > a problem to me.
> 
> Not for any wmi driver, only for those which would like to export wmi
> device to userspace.

Correct.

> 
> > This audience recommends the way for users to configure the system but 
> > of course cannot stop users from doing what they decide to do.  
> 
> Of course, but in above hypothetical example, user is in situation where
> is unable to use both 3rd vendor application and together kernel
> rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
> manual module loading) what want to use.
> 
> But ideal solution is that both 3rd vendor application for firmware
> settings and also rfkill kernel driver would work together without need
> to rmmod/modprobe modules and without restarting 3rd vendor application.
> 
> > We're all in agreement that the kernel should keep responsibility for some
> > of these functionalities.
> > If a new kernel WMI driver duplicates functionality that happens to find 
> > its 
> > way in userspace and the kernel audits that out yes the userspace 
> > application may start to  have less functionality, but better support 
> > would live in the kernel and the user would be better supported by 
> > the stack (for example could use standard rfkill userspace utilities).
> 

Pali has raised a very good point which I want to get some feedback from Linus,
and perhaps tglx, hpa, and gregkh on. While Mario is expressing a very pragmatic
approach which I certainly appreciate, we have a very strong position that we do
not break userspace.

There have been exceptions for specific pseudo filesystems and such, but they
are rare. We would need to document the WMI commitment from the kernel to
userspace (e.g. any call may be filtered based on current Linux kernel WMI
usage, which may change over time). This sounds troublesome... will give this
some more thought.

> Ok. So it is acceptable solution/API/ABI for you & other Dell people?
> Or is something more or different needed?
> 
> Darren, I hope that I understood your proposal with explicit whitelist
> correctly. And is there already another vendor which want to use wmi
> userspace on linux?

It might be moot with Christoph's dynamic ID comment which I need to go review
in detail. Putting that aside for a moment, what I intended was f

Re: RFC: WMI Enhancements

[Christoph Hellwig]

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.

Re: RFC: WMI Enhancements

[Christoph Hellwig]

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.

Re: RFC: WMI Enhancements

[Pali Rohár]

On Wednesday 19 April 2017 17:24:00 mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > Sent: Wednesday, April 19, 2017 11:55 AM
> > To: Limonciello, Mario <mario_limoncie...@dell.com>
> > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > Subject: Re: RFC: WMI Enhancements
> > 
> > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com wrote:
> > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > > will be exported to userspace after communication with vendor.
> > >
> > > What about GUID's not yet used by kernel drivers?  Would those
> > > default to whitelist default to blacklist?  My preference would be
> > > to default to whitelist. This allows new GUID's to be added later
> > > without needing to modify kernel for something that kernel won't
> > > need to do anything immediately.
> > 
> > I understood it as there would be explicit whitelist in kernel and new
> > GUIDs would be needed to add into whitelist, even those which do not
> > have kernel wmi driver.
> > 
> > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > has one big problem. If kernel introduce new wmi driver for such GUID
> > then it block userspace to access it or at least would need to provide
> > audit filter and something would be probably filtered. It means that
> > some userspace applications which would use that GUIDs stops working
> > after upgrading to new kernel. And we can be in situation where *user*
> > need to decide: either use 3rd party userspace application from vendor
> > which provide some special settings for your laptop, or use kernel
> > module which provides standard rfkill/led/input class driver.
> > 
> 
> If this proposal goes forward it would sound like to me an audit filter
> would become a prerequisite for any new WMI kernel driver.  This is not
> a problem to me.

Not for any wmi driver, only for those which would like to export wmi
device to userspace.

> This audience recommends the way for users to configure the system but 
> of course cannot stop users from doing what they decide to do.  

Of course, but in above hypothetical example, user is in situation where
is unable to use both 3rd vendor application and together kernel
rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
manual module loading) what want to use.

But ideal solution is that both 3rd vendor application for firmware
settings and also rfkill kernel driver would work together without need
to rmmod/modprobe modules and without restarting 3rd vendor application.

> We're all in agreement that the kernel should keep responsibility for some
> of these functionalities.
> If a new kernel WMI driver duplicates functionality that happens to find its 
> way in userspace and the kernel audits that out yes the userspace 
> application may start to  have less functionality, but better support 
> would live in the kernel and the user would be better supported by 
> the stack (for example could use standard rfkill userspace utilities).

Ok. So it is acceptable solution/API/ABI for you & other Dell people?
Or is something more or different needed?

Darren, I hope that I understood your proposal with explicit whitelist
correctly. And is there already another vendor which want to use wmi
userspace on linux?

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

Re: RFC: WMI Enhancements

[Pali Rohár]

On Wednesday 19 April 2017 17:24:00 mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > Sent: Wednesday, April 19, 2017 11:55 AM
> > To: Limonciello, Mario 
> > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > Subject: Re: RFC: WMI Enhancements
> > 
> > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com wrote:
> > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > > will be exported to userspace after communication with vendor.
> > >
> > > What about GUID's not yet used by kernel drivers?  Would those
> > > default to whitelist default to blacklist?  My preference would be
> > > to default to whitelist. This allows new GUID's to be added later
> > > without needing to modify kernel for something that kernel won't
> > > need to do anything immediately.
> > 
> > I understood it as there would be explicit whitelist in kernel and new
> > GUIDs would be needed to add into whitelist, even those which do not
> > have kernel wmi driver.
> > 
> > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > has one big problem. If kernel introduce new wmi driver for such GUID
> > then it block userspace to access it or at least would need to provide
> > audit filter and something would be probably filtered. It means that
> > some userspace applications which would use that GUIDs stops working
> > after upgrading to new kernel. And we can be in situation where *user*
> > need to decide: either use 3rd party userspace application from vendor
> > which provide some special settings for your laptop, or use kernel
> > module which provides standard rfkill/led/input class driver.
> > 
> 
> If this proposal goes forward it would sound like to me an audit filter
> would become a prerequisite for any new WMI kernel driver.  This is not
> a problem to me.

Not for any wmi driver, only for those which would like to export wmi
device to userspace.

> This audience recommends the way for users to configure the system but 
> of course cannot stop users from doing what they decide to do.  

Of course, but in above hypothetical example, user is in situation where
is unable to use both 3rd vendor application and together kernel
rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
manual module loading) what want to use.

But ideal solution is that both 3rd vendor application for firmware
settings and also rfkill kernel driver would work together without need
to rmmod/modprobe modules and without restarting 3rd vendor application.

> We're all in agreement that the kernel should keep responsibility for some
> of these functionalities.
> If a new kernel WMI driver duplicates functionality that happens to find its 
> way in userspace and the kernel audits that out yes the userspace 
> application may start to  have less functionality, but better support 
> would live in the kernel and the user would be better supported by 
> the stack (for example could use standard rfkill userspace utilities).

Ok. So it is acceptable solution/API/ABI for you & other Dell people?
Or is something more or different needed?

Darren, I hope that I understood your proposal with explicit whitelist
correctly. And is there already another vendor which want to use wmi
userspace on linux?

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

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Wednesday, April 19, 2017 11:55 AM
> To: Limonciello, Mario <mario_limoncie...@dell.com>
> Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com wrote:
> > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > will be exported to userspace after communication with vendor.
> >
> > What about GUID's not yet used by kernel drivers?  Would those
> > default to whitelist default to blacklist?  My preference would be
> > to default to whitelist. This allows new GUID's to be added later
> > without needing to modify kernel for something that kernel won't
> > need to do anything immediately.
> 
> I understood it as there would be explicit whitelist in kernel and new
> GUIDs would be needed to add into whitelist, even those which do not
> have kernel wmi driver.
> 
> Exporting all GUIDs (to userspace) which are not bind to kernel driver
> has one big problem. If kernel introduce new wmi driver for such GUID
> then it block userspace to access it or at least would need to provide
> audit filter and something would be probably filtered. It means that
> some userspace applications which would use that GUIDs stops working
> after upgrading to new kernel. And we can be in situation where *user*
> need to decide: either use 3rd party userspace application from vendor
> which provide some special settings for your laptop, or use kernel
> module which provides standard rfkill/led/input class driver.
> 

If this proposal goes forward it would sound like to me an audit filter
would become a prerequisite for any new WMI kernel driver.  This is not
a problem to me.

This audience recommends the way for users to configure the system but 
of course cannot stop users from doing what they decide to do.  
We're all in agreement that the kernel should keep responsibility for some
of these functionalities.
If a new kernel WMI driver duplicates functionality that happens to find its 
way in userspace and the kernel audits that out yes the userspace 
application may start to  have less functionality, but better support 
would live in the kernel and the user would be better supported by 
the stack (for example could use standard rfkill userspace utilities).

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Wednesday, April 19, 2017 11:55 AM
> To: Limonciello, Mario 
> Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com wrote:
> > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > will be exported to userspace after communication with vendor.
> >
> > What about GUID's not yet used by kernel drivers?  Would those
> > default to whitelist default to blacklist?  My preference would be
> > to default to whitelist. This allows new GUID's to be added later
> > without needing to modify kernel for something that kernel won't
> > need to do anything immediately.
> 
> I understood it as there would be explicit whitelist in kernel and new
> GUIDs would be needed to add into whitelist, even those which do not
> have kernel wmi driver.
> 
> Exporting all GUIDs (to userspace) which are not bind to kernel driver
> has one big problem. If kernel introduce new wmi driver for such GUID
> then it block userspace to access it or at least would need to provide
> audit filter and something would be probably filtered. It means that
> some userspace applications which would use that GUIDs stops working
> after upgrading to new kernel. And we can be in situation where *user*
> need to decide: either use 3rd party userspace application from vendor
> which provide some special settings for your laptop, or use kernel
> module which provides standard rfkill/led/input class driver.
> 

If this proposal goes forward it would sound like to me an audit filter
would become a prerequisite for any new WMI kernel driver.  This is not
a problem to me.

This audience recommends the way for users to configure the system but 
of course cannot stop users from doing what they decide to do.  
We're all in agreement that the kernel should keep responsibility for some
of these functionalities.
If a new kernel WMI driver duplicates functionality that happens to find its 
way in userspace and the kernel audits that out yes the userspace 
application may start to  have less functionality, but better support 
would live in the kernel and the user would be better supported by 
the stack (for example could use standard rfkill userspace utilities).

Re: RFC: WMI Enhancements

[Pali Rohár]

On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com wrote:
> > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > will be exported to userspace after communication with vendor.
> 
> What about GUID's not yet used by kernel drivers?  Would those
> default to whitelist default to blacklist?  My preference would be
> to default to whitelist. This allows new GUID's to be added later
> without needing to modify kernel for something that kernel won't
> need to do anything immediately.

I understood it as there would be explicit whitelist in kernel and new 
GUIDs would be needed to add into whitelist, even those which do not 
have kernel wmi driver.

Exporting all GUIDs (to userspace) which are not bind to kernel driver 
has one big problem. If kernel introduce new wmi driver for such GUID 
then it block userspace to access it or at least would need to provide 
audit filter and something would be probably filtered. It means that 
some userspace applications which would use that GUIDs stops working 
after upgrading to new kernel. And we can be in situation where *user* 
need to decide: either use 3rd party userspace application from vendor 
which provide some special settings for your laptop, or use kernel 
module which provides standard rfkill/led/input class driver.

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


signature.asc
Description: This is a digitally signed message part.

Re: RFC: WMI Enhancements

[Pali Rohár]

On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com wrote:
> > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > will be exported to userspace after communication with vendor.
> 
> What about GUID's not yet used by kernel drivers?  Would those
> default to whitelist default to blacklist?  My preference would be
> to default to whitelist. This allows new GUID's to be added later
> without needing to modify kernel for something that kernel won't
> need to do anything immediately.

I understood it as there would be explicit whitelist in kernel and new 
GUIDs would be needed to add into whitelist, even those which do not 
have kernel wmi driver.

Exporting all GUIDs (to userspace) which are not bind to kernel driver 
has one big problem. If kernel introduce new wmi driver for such GUID 
then it block userspace to access it or at least would need to provide 
audit filter and something would be probably filtered. It means that 
some userspace applications which would use that GUIDs stops working 
after upgrading to new kernel. And we can be in situation where *user* 
need to decide: either use 3rd party userspace application from vendor 
which provide some special settings for your laptop, or use kernel 
module which provides standard rfkill/led/input class driver.

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


signature.asc
Description: This is a digitally signed message part.

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Wednesday, April 19, 2017 2:53 AM
> To: Darren Hart <dvh...@infradead.org>
> Cc: Rafael J. Wysocki <r...@rjwysocki.net>; Andy Lutomirski
> <l...@amacapital.net>; Len Brown <len.br...@intel.com>; Corentin Chary
> <corentin.ch...@gmail.com>; Limonciello, Mario <mario_limoncie...@dell.com>;
> Andy Lutomirski <l...@kernel.org>; Andy Shevchenko
> <andriy.shevche...@linux.intel.com>; LKML <linux-kernel@vger.kernel.org>;
> platform-driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Tuesday 18 April 2017 15:49:31 Darren Hart wrote:
> > On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote:
> > > And still, if write audit filters for every one existing wmi driver in
> > > kernel, there still audit filter can say to userspace that current
> > > request cannot be accepted and sent to firmware.
> >
> > For the vast majority of platforms, the WMI interface would not be 
> > exported, and
> > we would not attempt to write audit filters. As a rule, I would expect this
> > effort to be triggered by a request from the vendor, and done only with 
> > their
> > explicit involvement after providing complete documentation of the WMI
> > interface.
> 
> Ok, if WMI interface would be exported to userspace only after previous
> communication with vendor, then this should be OK. It also means that we
> need to maintain list of WMI GUIDs...
> 
> > However, we would expect those filters to deny as few calls as possible for 
> > the
> > platforms that choose to export the WMI interface to userspace.
> 
> I expect that vendor would be communicate with kernel developers and
> filters would be written with agreement with vendor. This seems OK.
> 
> > For example, dell-wmi.c would be largely unaffected as the EVENT_GUID is not
> > interesting for userspace (per Mario) and would not be exported. The 
> > Descriptor
> > GUID should be safe to share with userspace, at least for the way we use it 
> > in
> > the kernel. Similar for dell-wmi-aio.c
> >
> > For dell-wmi-led.c, we could most likely not export the GUID at all, but if 
> > we
> > did, we could choose to filter on device_id or command from the bios_args 
> > used
> > in the input buffer.
> >
> > I don't think I've seen exactly what the WMI interface for the existing 
> > SMBIOS
> > stuff will look like, but we seem to have a fairly structured way of 
> > accessing it
> > today, which should allow us to filter out those specific usages (such as
> > rfkill). Additionally, the concern that userspace can make use of the same
> > mechanism as the kernel is where we are today with libsmbios.
> >
> > With WMI filters, we could, for example, deny all DELL_SMBIOS_WMI GUID calls
> > equivalent to "class 17, select 11" (Wireless control), since that is 
> > handled
> > internally. Similarly for "4,11" (KBD ALS).
> >
> > >
> > > This would mean that userspace application would not be able to do ANY
> > > WMI method call (as e.g. on windows) and so for some vendors it can be
> > > useless.
> >
> > We address this with more granular filters.
> >
> > > And here I'm not sure, how hard would be to write those audit filters
> > > for all wmi kernel drivers and if it would be possible without wmi
> > > documentation of those vendor apis (which we do not have).
> >
> > As above, we won't write them for every wmi kernel driver. Only for those
> > vendors which engage with us to do so.
> >
> > > Potential vendors can decide based on above fact, that their userspace
> > > application rather rmmod wmi kernel driver for particular GUID (which
> > > release occupation of wmi device) and their userspace application starts
> > > working. And this is I think situation which is bad for kernel and we
> > > should prevent it.
> >
> > I agree we would want to avoid this. As this is off by default and only 
> > enabled
> > / implemented with the cooperation of the vendor in the first place, I 
> > suspect
> > this kind of antagonistic interaction is unlikely.
> >
> > You previously mentioned doing a vendor specific interface. This was my 
> > initial
> > response as well, but it doesn't meet the intent of the WMI interface, nor 
> > the
> > needs of vendors like Dell. That is, it requires a priori knowledge of all
> > current and future interfaces, and/or the continu

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Wednesday, April 19, 2017 2:53 AM
> To: Darren Hart 
> Cc: Rafael J. Wysocki ; Andy Lutomirski
> ; Len Brown ; Corentin Chary
> ; Limonciello, Mario ;
> Andy Lutomirski ; Andy Shevchenko
> ; LKML ;
> platform-driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Tuesday 18 April 2017 15:49:31 Darren Hart wrote:
> > On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote:
> > > And still, if write audit filters for every one existing wmi driver in
> > > kernel, there still audit filter can say to userspace that current
> > > request cannot be accepted and sent to firmware.
> >
> > For the vast majority of platforms, the WMI interface would not be 
> > exported, and
> > we would not attempt to write audit filters. As a rule, I would expect this
> > effort to be triggered by a request from the vendor, and done only with 
> > their
> > explicit involvement after providing complete documentation of the WMI
> > interface.
> 
> Ok, if WMI interface would be exported to userspace only after previous
> communication with vendor, then this should be OK. It also means that we
> need to maintain list of WMI GUIDs...
> 
> > However, we would expect those filters to deny as few calls as possible for 
> > the
> > platforms that choose to export the WMI interface to userspace.
> 
> I expect that vendor would be communicate with kernel developers and
> filters would be written with agreement with vendor. This seems OK.
> 
> > For example, dell-wmi.c would be largely unaffected as the EVENT_GUID is not
> > interesting for userspace (per Mario) and would not be exported. The 
> > Descriptor
> > GUID should be safe to share with userspace, at least for the way we use it 
> > in
> > the kernel. Similar for dell-wmi-aio.c
> >
> > For dell-wmi-led.c, we could most likely not export the GUID at all, but if 
> > we
> > did, we could choose to filter on device_id or command from the bios_args 
> > used
> > in the input buffer.
> >
> > I don't think I've seen exactly what the WMI interface for the existing 
> > SMBIOS
> > stuff will look like, but we seem to have a fairly structured way of 
> > accessing it
> > today, which should allow us to filter out those specific usages (such as
> > rfkill). Additionally, the concern that userspace can make use of the same
> > mechanism as the kernel is where we are today with libsmbios.
> >
> > With WMI filters, we could, for example, deny all DELL_SMBIOS_WMI GUID calls
> > equivalent to "class 17, select 11" (Wireless control), since that is 
> > handled
> > internally. Similarly for "4,11" (KBD ALS).
> >
> > >
> > > This would mean that userspace application would not be able to do ANY
> > > WMI method call (as e.g. on windows) and so for some vendors it can be
> > > useless.
> >
> > We address this with more granular filters.
> >
> > > And here I'm not sure, how hard would be to write those audit filters
> > > for all wmi kernel drivers and if it would be possible without wmi
> > > documentation of those vendor apis (which we do not have).
> >
> > As above, we won't write them for every wmi kernel driver. Only for those
> > vendors which engage with us to do so.
> >
> > > Potential vendors can decide based on above fact, that their userspace
> > > application rather rmmod wmi kernel driver for particular GUID (which
> > > release occupation of wmi device) and their userspace application starts
> > > working. And this is I think situation which is bad for kernel and we
> > > should prevent it.
> >
> > I agree we would want to avoid this. As this is off by default and only 
> > enabled
> > / implemented with the cooperation of the vendor in the first place, I 
> > suspect
> > this kind of antagonistic interaction is unlikely.
> >
> > You previously mentioned doing a vendor specific interface. This was my 
> > initial
> > response as well, but it doesn't meet the intent of the WMI interface, nor 
> > the
> > needs of vendors like Dell. That is, it requires a priori knowledge of all
> > current and future interfaces, and/or the continued gating on the Linux 
> > kernel
> > in order to allow a new method/interface. Further, by creating these 
> > interfaces,
> > we become more tied to them, and they will grow over time, until they are a 
> > very
> > large set of mo

Re: RFC: WMI Enhancements

[Pali Rohár]

On Tuesday 18 April 2017 15:49:31 Darren Hart wrote:
> On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote:
> > And still, if write audit filters for every one existing wmi driver in 
> > kernel, there still audit filter can say to userspace that current 
> > request cannot be accepted and sent to firmware.
> 
> For the vast majority of platforms, the WMI interface would not be exported, 
> and
> we would not attempt to write audit filters. As a rule, I would expect this
> effort to be triggered by a request from the vendor, and done only with their
> explicit involvement after providing complete documentation of the WMI
> interface.

Ok, if WMI interface would be exported to userspace only after previous
communication with vendor, then this should be OK. It also means that we
need to maintain list of WMI GUIDs...

> However, we would expect those filters to deny as few calls as possible for 
> the
> platforms that choose to export the WMI interface to userspace.

I expect that vendor would be communicate with kernel developers and
filters would be written with agreement with vendor. This seems OK.

> For example, dell-wmi.c would be largely unaffected as the EVENT_GUID is not
> interesting for userspace (per Mario) and would not be exported. The 
> Descriptor
> GUID should be safe to share with userspace, at least for the way we use it in
> the kernel. Similar for dell-wmi-aio.c
> 
> For dell-wmi-led.c, we could most likely not export the GUID at all, but if we
> did, we could choose to filter on device_id or command from the bios_args used
> in the input buffer.
> 
> I don't think I've seen exactly what the WMI interface for the existing SMBIOS
> stuff will look like, but we seem to have a fairly structured way of 
> accessing it
> today, which should allow us to filter out those specific usages (such as
> rfkill). Additionally, the concern that userspace can make use of the same
> mechanism as the kernel is where we are today with libsmbios.
> 
> With WMI filters, we could, for example, deny all DELL_SMBIOS_WMI GUID calls
> equivalent to "class 17, select 11" (Wireless control), since that is handled
> internally. Similarly for "4,11" (KBD ALS).
> 
> > 
> > This would mean that userspace application would not be able to do ANY 
> > WMI method call (as e.g. on windows) and so for some vendors it can be 
> > useless.
> 
> We address this with more granular filters.
> 
> > And here I'm not sure, how hard would be to write those audit filters 
> > for all wmi kernel drivers and if it would be possible without wmi 
> > documentation of those vendor apis (which we do not have).
> 
> As above, we won't write them for every wmi kernel driver. Only for those
> vendors which engage with us to do so.
> 
> > Potential vendors can decide based on above fact, that their userspace 
> > application rather rmmod wmi kernel driver for particular GUID (which 
> > release occupation of wmi device) and their userspace application starts 
> > working. And this is I think situation which is bad for kernel and we 
> > should prevent it.
> 
> I agree we would want to avoid this. As this is off by default and only 
> enabled
> / implemented with the cooperation of the vendor in the first place, I suspect
> this kind of antagonistic interaction is unlikely.
> 
> You previously mentioned doing a vendor specific interface. This was my 
> initial
> response as well, but it doesn't meet the intent of the WMI interface, nor the
> needs of vendors like Dell. That is, it requires a priori knowledge of all
> current and future interfaces, and/or the continued gating on the Linux kernel
> in order to allow a new method/interface. Further, by creating these 
> interfaces,
> we become more tied to them, and they will grow over time, until they are a 
> very
> large set of mostly deprecated interfaces which we can't remove for legacy
> reasons.

Benefit of vendor specific API is code de-duplication and having common
functions in one place. E.g. code for changing SMBIOS token does not
have to be implemented in both userspace and kernel, just in kernel.

Also handling generic API requests from userspace in kernel and then
pass them to firmware is a bit harder and less error prone. Also audit
filters would be less easier...

I still think that we do not have to export WMI as is to userspace and
personally I do not think it is the best solution even if Microsoft is
doing it...

But if we are unable to design such API and vendor (e.g. Dell) already
wants WMI API in userspace, then we probably should export it from them.

> All that said, I appreciate the concerns you've raised and they mirror many of
> my own. I don't think we can just say "no, Windows Management Instrumentation 
> is
> only accessible in Linux within the kernel" as that is ultimately contrary to
> the purpose of the mechanism. With those concerns in mind, I proposed the
> general approach below which affords considerable freedom for vendors to 
> manage
> their systems 

Re: RFC: WMI Enhancements

[Pali Rohár]

On Tuesday 18 April 2017 15:49:31 Darren Hart wrote:
> On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote:
> > And still, if write audit filters for every one existing wmi driver in 
> > kernel, there still audit filter can say to userspace that current 
> > request cannot be accepted and sent to firmware.
> 
> For the vast majority of platforms, the WMI interface would not be exported, 
> and
> we would not attempt to write audit filters. As a rule, I would expect this
> effort to be triggered by a request from the vendor, and done only with their
> explicit involvement after providing complete documentation of the WMI
> interface.

Ok, if WMI interface would be exported to userspace only after previous
communication with vendor, then this should be OK. It also means that we
need to maintain list of WMI GUIDs...

> However, we would expect those filters to deny as few calls as possible for 
> the
> platforms that choose to export the WMI interface to userspace.

I expect that vendor would be communicate with kernel developers and
filters would be written with agreement with vendor. This seems OK.

> For example, dell-wmi.c would be largely unaffected as the EVENT_GUID is not
> interesting for userspace (per Mario) and would not be exported. The 
> Descriptor
> GUID should be safe to share with userspace, at least for the way we use it in
> the kernel. Similar for dell-wmi-aio.c
> 
> For dell-wmi-led.c, we could most likely not export the GUID at all, but if we
> did, we could choose to filter on device_id or command from the bios_args used
> in the input buffer.
> 
> I don't think I've seen exactly what the WMI interface for the existing SMBIOS
> stuff will look like, but we seem to have a fairly structured way of 
> accessing it
> today, which should allow us to filter out those specific usages (such as
> rfkill). Additionally, the concern that userspace can make use of the same
> mechanism as the kernel is where we are today with libsmbios.
> 
> With WMI filters, we could, for example, deny all DELL_SMBIOS_WMI GUID calls
> equivalent to "class 17, select 11" (Wireless control), since that is handled
> internally. Similarly for "4,11" (KBD ALS).
> 
> > 
> > This would mean that userspace application would not be able to do ANY 
> > WMI method call (as e.g. on windows) and so for some vendors it can be 
> > useless.
> 
> We address this with more granular filters.
> 
> > And here I'm not sure, how hard would be to write those audit filters 
> > for all wmi kernel drivers and if it would be possible without wmi 
> > documentation of those vendor apis (which we do not have).
> 
> As above, we won't write them for every wmi kernel driver. Only for those
> vendors which engage with us to do so.
> 
> > Potential vendors can decide based on above fact, that their userspace 
> > application rather rmmod wmi kernel driver for particular GUID (which 
> > release occupation of wmi device) and their userspace application starts 
> > working. And this is I think situation which is bad for kernel and we 
> > should prevent it.
> 
> I agree we would want to avoid this. As this is off by default and only 
> enabled
> / implemented with the cooperation of the vendor in the first place, I suspect
> this kind of antagonistic interaction is unlikely.
> 
> You previously mentioned doing a vendor specific interface. This was my 
> initial
> response as well, but it doesn't meet the intent of the WMI interface, nor the
> needs of vendors like Dell. That is, it requires a priori knowledge of all
> current and future interfaces, and/or the continued gating on the Linux kernel
> in order to allow a new method/interface. Further, by creating these 
> interfaces,
> we become more tied to them, and they will grow over time, until they are a 
> very
> large set of mostly deprecated interfaces which we can't remove for legacy
> reasons.

Benefit of vendor specific API is code de-duplication and having common
functions in one place. E.g. code for changing SMBIOS token does not
have to be implemented in both userspace and kernel, just in kernel.

Also handling generic API requests from userspace in kernel and then
pass them to firmware is a bit harder and less error prone. Also audit
filters would be less easier...

I still think that we do not have to export WMI as is to userspace and
personally I do not think it is the best solution even if Microsoft is
doing it...

But if we are unable to design such API and vendor (e.g. Dell) already
wants WMI API in userspace, then we probably should export it from them.

> All that said, I appreciate the concerns you've raised and they mirror many of
> my own. I don't think we can just say "no, Windows Management Instrumentation 
> is
> only accessible in Linux within the kernel" as that is ultimately contrary to
> the purpose of the mechanism. With those concerns in mind, I proposed the
> general approach below which affords considerable freedom for vendors to 
> manage
> their systems 

Re: RFC: WMI Enhancements

[Darren Hart]

On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote:
> On Tuesday 18 April 2017 18:33:25 Darren Hart wrote:
> > On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
> > > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> > > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart
> > > > >  wrote:
> > > > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki
> > > > > > wrote:
> > > > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > > > > >> > Hi All,
> > > > > >> > 
> > > > > >> > There are a few parallel efforts involving the Windows
> > > > > >> > Management Instrumentation (WMI)[1] and dependent/related
> > > > > >> > drivers. I'd like to have a round of discussion among
> > > > > >> > those of you that have been involved in this space before
> > > > > >> > we decide on a direction.
> > > > > >> > 
> > > > > >> > The WMI support in the kernel today fairly narrowly
> > > > > >> > supports a handful of systems. Andy L. has a
> > > > > >> > work-in-progress series [2] which converts wmi into a
> > > > > >> > platform device and a proper bus, providing devices for
> > > > > >> > dependent drivers to bind to, and a mechanism for sibling
> > > > > >> > devices to communicate with each other. I've reviewed the
> > > > > >> > series and feel like the approach is sound, I plan to
> > > > > >> > carry this series forward and merge it (with Andy L's
> > > > > >> > permission).
> > > > > >> > 
> > > > > >> > Are there any objections to this?
> > > > > >> > 
> > > > > >> > In Windows, applications interact with WMI more or less
> > > > > >> > directly. We don't do this in Linux currently, although
> > > > > >> > it has been discussed in the past [3]. Some vendors will
> > > > > >> > work around this by performing SMI/SMM, which is
> > > > > >> > inefficient at best. Exposing WMI methods to userspace
> > > > > >> > would bring parity to WMI for Linux and Windows.
> > > > > >> > 
> > > > > >> > There are two principal concerns I'd appreciate your
> > > > > >> > thoughts on:
> > > > > >> > 
> > > > > >> > a) As an undiscoverable interface (you need to know the
> > > > > >> > method signatures ahead of time), universally exposing
> > > > > >> > every WMI "device" to userspace seems like "a bad idea"
> > > > > >> > from a security and stability perspective. While access
> > > > > >> > would certainly be privileged, it seems more prudent to
> > > > > >> > make this exposure opt-in. We also handle some of this
> > > > > >> > with kernel drivers and exposing those "devices" to
> > > > > >> > userspace would enable userspace and the kernel to fight
> > > > > >> > over control. So - if we expose WMI devices to userspace,
> > > > > >> > I believe this should be done on a case by case basis,
> > > > > >> > opting in, and not by default as part of the WMI driver
> > > > > >> > (although it can provide the mechanism for a sub-driver
> > > > > >> > to use), and possibly a devmode to do so by default.
> > > > > >> 
> > > > > >> A couple of loose thoughts here.
> > > > > >> 
> > > > > >> In principle there could be a "generic default WMI driver"
> > > > > >> or similar that would "claim" all WMI "devices" that have
> > > > > >> not been "claimed" by anyone else and would simply expose
> > > > > >> them to user space somehow (e.g. using a chardev
> > > > > >> interface).
> > > > > >> 
> > > > > >> Then, depending on how that thing is implemented, opt-in etc
> > > > > >> should be possible too.
> > > > > > 
> > > > > > I think we agree this would be an ideal approach.
> > > > > > 
> > > > > > As we look into this more, it is becoming clear that the
> > > > > > necessary functionality is not nicely divided into GUIDs for
> > > > > > what is necessary in userspace and what is handled in the
> > > > > > kernel. A single WMI METHOD GUID may be needed by userspace
> > > > > > for certain functionality, while the kernel drivers may use
> > > > > > it for something else.
> > > > > > 
> > > > > > :-(
> > > > > > 
> > > > > > The input to a WMI method is just a buffer, so it is very
> > > > > > free form. One approach Mario has mentioned was to audit the
> > > > > > user space WMI METHOD calls in the kernel platform drivers
> > > > > > and reject those calls with arguments matching those issued
> > > > > > by the kernel driver. This is likely to be complex and error
> > > > > > prone in my opinion. However, I have not yet thought of
> > > > > > another means to meet the requirement of having disjoint
> > > > > > feature sets for userspace and kernel space via a mechanism
> > > > > > that was effectively designed to be used solely from user
> > > > > > space with vendor defined method signatures.
> > > > > > 
> > > > > > Next step is to look at just how complex it would be to audit
> > > > > > the method calls the kernel currently uses.
> > > > > 
> > > > > I'm wondering whether it's really worth it.  

Re: RFC: WMI Enhancements

[Darren Hart]

On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote:
> On Tuesday 18 April 2017 18:33:25 Darren Hart wrote:
> > On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
> > > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> > > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart
> > > > >  wrote:
> > > > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki
> > > > > > wrote:
> > > > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > > > > >> > Hi All,
> > > > > >> > 
> > > > > >> > There are a few parallel efforts involving the Windows
> > > > > >> > Management Instrumentation (WMI)[1] and dependent/related
> > > > > >> > drivers. I'd like to have a round of discussion among
> > > > > >> > those of you that have been involved in this space before
> > > > > >> > we decide on a direction.
> > > > > >> > 
> > > > > >> > The WMI support in the kernel today fairly narrowly
> > > > > >> > supports a handful of systems. Andy L. has a
> > > > > >> > work-in-progress series [2] which converts wmi into a
> > > > > >> > platform device and a proper bus, providing devices for
> > > > > >> > dependent drivers to bind to, and a mechanism for sibling
> > > > > >> > devices to communicate with each other. I've reviewed the
> > > > > >> > series and feel like the approach is sound, I plan to
> > > > > >> > carry this series forward and merge it (with Andy L's
> > > > > >> > permission).
> > > > > >> > 
> > > > > >> > Are there any objections to this?
> > > > > >> > 
> > > > > >> > In Windows, applications interact with WMI more or less
> > > > > >> > directly. We don't do this in Linux currently, although
> > > > > >> > it has been discussed in the past [3]. Some vendors will
> > > > > >> > work around this by performing SMI/SMM, which is
> > > > > >> > inefficient at best. Exposing WMI methods to userspace
> > > > > >> > would bring parity to WMI for Linux and Windows.
> > > > > >> > 
> > > > > >> > There are two principal concerns I'd appreciate your
> > > > > >> > thoughts on:
> > > > > >> > 
> > > > > >> > a) As an undiscoverable interface (you need to know the
> > > > > >> > method signatures ahead of time), universally exposing
> > > > > >> > every WMI "device" to userspace seems like "a bad idea"
> > > > > >> > from a security and stability perspective. While access
> > > > > >> > would certainly be privileged, it seems more prudent to
> > > > > >> > make this exposure opt-in. We also handle some of this
> > > > > >> > with kernel drivers and exposing those "devices" to
> > > > > >> > userspace would enable userspace and the kernel to fight
> > > > > >> > over control. So - if we expose WMI devices to userspace,
> > > > > >> > I believe this should be done on a case by case basis,
> > > > > >> > opting in, and not by default as part of the WMI driver
> > > > > >> > (although it can provide the mechanism for a sub-driver
> > > > > >> > to use), and possibly a devmode to do so by default.
> > > > > >> 
> > > > > >> A couple of loose thoughts here.
> > > > > >> 
> > > > > >> In principle there could be a "generic default WMI driver"
> > > > > >> or similar that would "claim" all WMI "devices" that have
> > > > > >> not been "claimed" by anyone else and would simply expose
> > > > > >> them to user space somehow (e.g. using a chardev
> > > > > >> interface).
> > > > > >> 
> > > > > >> Then, depending on how that thing is implemented, opt-in etc
> > > > > >> should be possible too.
> > > > > > 
> > > > > > I think we agree this would be an ideal approach.
> > > > > > 
> > > > > > As we look into this more, it is becoming clear that the
> > > > > > necessary functionality is not nicely divided into GUIDs for
> > > > > > what is necessary in userspace and what is handled in the
> > > > > > kernel. A single WMI METHOD GUID may be needed by userspace
> > > > > > for certain functionality, while the kernel drivers may use
> > > > > > it for something else.
> > > > > > 
> > > > > > :-(
> > > > > > 
> > > > > > The input to a WMI method is just a buffer, so it is very
> > > > > > free form. One approach Mario has mentioned was to audit the
> > > > > > user space WMI METHOD calls in the kernel platform drivers
> > > > > > and reject those calls with arguments matching those issued
> > > > > > by the kernel driver. This is likely to be complex and error
> > > > > > prone in my opinion. However, I have not yet thought of
> > > > > > another means to meet the requirement of having disjoint
> > > > > > feature sets for userspace and kernel space via a mechanism
> > > > > > that was effectively designed to be used solely from user
> > > > > > space with vendor defined method signatures.
> > > > > > 
> > > > > > Next step is to look at just how complex it would be to audit
> > > > > > the method calls the kernel currently uses.
> > > > > 
> > > > > I'm wondering whether it's really worth it.  We already allow
> > > 

Re: RFC: WMI Enhancements

[Rafael J. Wysocki]

On Tue, Apr 18, 2017 at 6:33 PM, Darren Hart  wrote:
> On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
>> On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
>> > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
>> > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart  
>> > > wrote:
>> > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
>> > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
>> > > >> > Hi All,
>> > > >> >
>> > > >> > There are a few parallel efforts involving the Windows Management
>> > > >> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to 
>> > > >> > have a round of
>> > > >> > discussion among those of you that have been involved in this space 
>> > > >> > before we
>> > > >> > decide on a direction.
>> > > >> >
>> > > >> > The WMI support in the kernel today fairly narrowly supports a 
>> > > >> > handful of
>> > > >> > systems. Andy L. has a work-in-progress series [2] which converts 
>> > > >> > wmi into a
>> > > >> > platform device and a proper bus, providing devices for dependent 
>> > > >> > drivers to
>> > > >> > bind to, and a mechanism for sibling devices to communicate with 
>> > > >> > each other.
>> > > >> > I've reviewed the series and feel like the approach is sound, I 
>> > > >> > plan to carry
>> > > >> > this series forward and merge it (with Andy L's permission).
>> > > >> >
>> > > >> > Are there any objections to this?
>> > > >> >
>> > > >> > In Windows, applications interact with WMI more or less directly. 
>> > > >> > We don't do
>> > > >> > this in Linux currently, although it has been discussed in the past 
>> > > >> > [3]. Some
>> > > >> > vendors will work around this by performing SMI/SMM, which is 
>> > > >> > inefficient at
>> > > >> > best. Exposing WMI methods to userspace would bring parity to WMI 
>> > > >> > for Linux and
>> > > >> > Windows.
>> > > >> >
>> > > >> > There are two principal concerns I'd appreciate your thoughts on:
>> > > >> >
>> > > >> > a) As an undiscoverable interface (you need to know the method 
>> > > >> > signatures ahead
>> > > >> > of time), universally exposing every WMI "device" to userspace 
>> > > >> > seems like "a bad
>> > > >> > idea" from a security and stability perspective. While access would 
>> > > >> > certainly be
>> > > >> > privileged, it seems more prudent to make this exposure opt-in. We 
>> > > >> > also handle
>> > > >> > some of this with kernel drivers and exposing those "devices" to 
>> > > >> > userspace would
>> > > >> > enable userspace and the kernel to fight over control. So - if we 
>> > > >> > expose WMI
>> > > >> > devices to userspace, I believe this should be done on a case by 
>> > > >> > case basis,
>> > > >> > opting in, and not by default as part of the WMI driver (although 
>> > > >> > it can provide
>> > > >> > the mechanism for a sub-driver to use), and possibly a devmode to 
>> > > >> > do so by
>> > > >> > default.
>> > > >>
>> > > >> A couple of loose thoughts here.
>> > > >>
>> > > >> In principle there could be a "generic default WMI driver" or similar 
>> > > >> that would
>> > > >> "claim" all WMI "devices" that have not been "claimed" by anyone else 
>> > > >> and would
>> > > >> simply expose them to user space somehow (e.g. using a chardev 
>> > > >> interface).
>> > > >>
>> > > >> Then, depending on how that thing is implemented, opt-in etc should 
>> > > >> be possible
>> > > >> too.
>> > > >>
>> > > >
>> > > > I think we agree this would be an ideal approach.
>> > > >
>> > > > As we look into this more, it is becoming clear that the necessary 
>> > > > functionality
>> > > > is not nicely divided into GUIDs for what is necessary in userspace 
>> > > > and what is
>> > > > handled in the kernel. A single WMI METHOD GUID may be needed by 
>> > > > userspace for
>> > > > certain functionality, while the kernel drivers may use it for 
>> > > > something else.
>> > > >
>> > > > :-(
>> > > >
>> > > > The input to a WMI method is just a buffer, so it is very free form. 
>> > > > One
>> > > > approach Mario has mentioned was to audit the user space WMI METHOD 
>> > > > calls in the
>> > > > kernel platform drivers and reject those calls with arguments matching 
>> > > > those
>> > > > issued by the kernel driver. This is likely to be complex and error 
>> > > > prone in my
>> > > > opinion. However, I have not yet thought of another means to meet the
>> > > > requirement of having disjoint feature sets for userspace and kernel 
>> > > > space via a
>> > > > mechanism that was effectively designed to be used solely from user 
>> > > > space with
>> > > > vendor defined method signatures.
>> > > >
>> > > > Next step is to look at just how complex it would be to audit the 
>> > > > method calls
>> > > > the kernel currently uses.
>> > >
>> > > I'm wondering whether it's really worth it.  We already allow doing
>> > > darned near anything using dcdbas.  

Re: RFC: WMI Enhancements

[Rafael J. Wysocki]

On Tue, Apr 18, 2017 at 6:33 PM, Darren Hart  wrote:
> On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
>> On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
>> > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
>> > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart  
>> > > wrote:
>> > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
>> > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
>> > > >> > Hi All,
>> > > >> >
>> > > >> > There are a few parallel efforts involving the Windows Management
>> > > >> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to 
>> > > >> > have a round of
>> > > >> > discussion among those of you that have been involved in this space 
>> > > >> > before we
>> > > >> > decide on a direction.
>> > > >> >
>> > > >> > The WMI support in the kernel today fairly narrowly supports a 
>> > > >> > handful of
>> > > >> > systems. Andy L. has a work-in-progress series [2] which converts 
>> > > >> > wmi into a
>> > > >> > platform device and a proper bus, providing devices for dependent 
>> > > >> > drivers to
>> > > >> > bind to, and a mechanism for sibling devices to communicate with 
>> > > >> > each other.
>> > > >> > I've reviewed the series and feel like the approach is sound, I 
>> > > >> > plan to carry
>> > > >> > this series forward and merge it (with Andy L's permission).
>> > > >> >
>> > > >> > Are there any objections to this?
>> > > >> >
>> > > >> > In Windows, applications interact with WMI more or less directly. 
>> > > >> > We don't do
>> > > >> > this in Linux currently, although it has been discussed in the past 
>> > > >> > [3]. Some
>> > > >> > vendors will work around this by performing SMI/SMM, which is 
>> > > >> > inefficient at
>> > > >> > best. Exposing WMI methods to userspace would bring parity to WMI 
>> > > >> > for Linux and
>> > > >> > Windows.
>> > > >> >
>> > > >> > There are two principal concerns I'd appreciate your thoughts on:
>> > > >> >
>> > > >> > a) As an undiscoverable interface (you need to know the method 
>> > > >> > signatures ahead
>> > > >> > of time), universally exposing every WMI "device" to userspace 
>> > > >> > seems like "a bad
>> > > >> > idea" from a security and stability perspective. While access would 
>> > > >> > certainly be
>> > > >> > privileged, it seems more prudent to make this exposure opt-in. We 
>> > > >> > also handle
>> > > >> > some of this with kernel drivers and exposing those "devices" to 
>> > > >> > userspace would
>> > > >> > enable userspace and the kernel to fight over control. So - if we 
>> > > >> > expose WMI
>> > > >> > devices to userspace, I believe this should be done on a case by 
>> > > >> > case basis,
>> > > >> > opting in, and not by default as part of the WMI driver (although 
>> > > >> > it can provide
>> > > >> > the mechanism for a sub-driver to use), and possibly a devmode to 
>> > > >> > do so by
>> > > >> > default.
>> > > >>
>> > > >> A couple of loose thoughts here.
>> > > >>
>> > > >> In principle there could be a "generic default WMI driver" or similar 
>> > > >> that would
>> > > >> "claim" all WMI "devices" that have not been "claimed" by anyone else 
>> > > >> and would
>> > > >> simply expose them to user space somehow (e.g. using a chardev 
>> > > >> interface).
>> > > >>
>> > > >> Then, depending on how that thing is implemented, opt-in etc should 
>> > > >> be possible
>> > > >> too.
>> > > >>
>> > > >
>> > > > I think we agree this would be an ideal approach.
>> > > >
>> > > > As we look into this more, it is becoming clear that the necessary 
>> > > > functionality
>> > > > is not nicely divided into GUIDs for what is necessary in userspace 
>> > > > and what is
>> > > > handled in the kernel. A single WMI METHOD GUID may be needed by 
>> > > > userspace for
>> > > > certain functionality, while the kernel drivers may use it for 
>> > > > something else.
>> > > >
>> > > > :-(
>> > > >
>> > > > The input to a WMI method is just a buffer, so it is very free form. 
>> > > > One
>> > > > approach Mario has mentioned was to audit the user space WMI METHOD 
>> > > > calls in the
>> > > > kernel platform drivers and reject those calls with arguments matching 
>> > > > those
>> > > > issued by the kernel driver. This is likely to be complex and error 
>> > > > prone in my
>> > > > opinion. However, I have not yet thought of another means to meet the
>> > > > requirement of having disjoint feature sets for userspace and kernel 
>> > > > space via a
>> > > > mechanism that was effectively designed to be used solely from user 
>> > > > space with
>> > > > vendor defined method signatures.
>> > > >
>> > > > Next step is to look at just how complex it would be to audit the 
>> > > > method calls
>> > > > the kernel currently uses.
>> > >
>> > > I'm wondering whether it's really worth it.  We already allow doing
>> > > darned near anything using dcdbas.  Maybe the world won't end if we
>> > > expose a 

Re: RFC: WMI Enhancements

[Pali Rohár]

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

Ok.

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

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

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

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

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

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

I'm sure that specific API/ABI designed for concrete usage (here in 
Dell) would be easier and also better in resolving conflicts and 
fighting between kernel & userspace 

Re: RFC: WMI Enhancements

[Pali Rohár]

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

Ok.

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

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

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

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

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

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

I'm sure that specific API/ABI designed for concrete usage (here in 
Dell) would be easier and also better in resolving conflicts and 
fighting between kernel & userspace 

Re: RFC: WMI Enhancements

[Pali Rohár]

On Tuesday 18 April 2017 18:33:25 Darren Hart wrote:
> On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
> > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart
> > > >  wrote:
> > > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki
> > > > > wrote:
> > > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > > > >> > Hi All,
> > > > >> > 
> > > > >> > There are a few parallel efforts involving the Windows
> > > > >> > Management Instrumentation (WMI)[1] and dependent/related
> > > > >> > drivers. I'd like to have a round of discussion among
> > > > >> > those of you that have been involved in this space before
> > > > >> > we decide on a direction.
> > > > >> > 
> > > > >> > The WMI support in the kernel today fairly narrowly
> > > > >> > supports a handful of systems. Andy L. has a
> > > > >> > work-in-progress series [2] which converts wmi into a
> > > > >> > platform device and a proper bus, providing devices for
> > > > >> > dependent drivers to bind to, and a mechanism for sibling
> > > > >> > devices to communicate with each other. I've reviewed the
> > > > >> > series and feel like the approach is sound, I plan to
> > > > >> > carry this series forward and merge it (with Andy L's
> > > > >> > permission).
> > > > >> > 
> > > > >> > Are there any objections to this?
> > > > >> > 
> > > > >> > In Windows, applications interact with WMI more or less
> > > > >> > directly. We don't do this in Linux currently, although
> > > > >> > it has been discussed in the past [3]. Some vendors will
> > > > >> > work around this by performing SMI/SMM, which is
> > > > >> > inefficient at best. Exposing WMI methods to userspace
> > > > >> > would bring parity to WMI for Linux and Windows.
> > > > >> > 
> > > > >> > There are two principal concerns I'd appreciate your
> > > > >> > thoughts on:
> > > > >> > 
> > > > >> > a) As an undiscoverable interface (you need to know the
> > > > >> > method signatures ahead of time), universally exposing
> > > > >> > every WMI "device" to userspace seems like "a bad idea"
> > > > >> > from a security and stability perspective. While access
> > > > >> > would certainly be privileged, it seems more prudent to
> > > > >> > make this exposure opt-in. We also handle some of this
> > > > >> > with kernel drivers and exposing those "devices" to
> > > > >> > userspace would enable userspace and the kernel to fight
> > > > >> > over control. So - if we expose WMI devices to userspace,
> > > > >> > I believe this should be done on a case by case basis,
> > > > >> > opting in, and not by default as part of the WMI driver
> > > > >> > (although it can provide the mechanism for a sub-driver
> > > > >> > to use), and possibly a devmode to do so by default.
> > > > >> 
> > > > >> A couple of loose thoughts here.
> > > > >> 
> > > > >> In principle there could be a "generic default WMI driver"
> > > > >> or similar that would "claim" all WMI "devices" that have
> > > > >> not been "claimed" by anyone else and would simply expose
> > > > >> them to user space somehow (e.g. using a chardev
> > > > >> interface).
> > > > >> 
> > > > >> Then, depending on how that thing is implemented, opt-in etc
> > > > >> should be possible too.
> > > > > 
> > > > > I think we agree this would be an ideal approach.
> > > > > 
> > > > > As we look into this more, it is becoming clear that the
> > > > > necessary functionality is not nicely divided into GUIDs for
> > > > > what is necessary in userspace and what is handled in the
> > > > > kernel. A single WMI METHOD GUID may be needed by userspace
> > > > > for certain functionality, while the kernel drivers may use
> > > > > it for something else.
> > > > > 
> > > > > :-(
> > > > > 
> > > > > The input to a WMI method is just a buffer, so it is very
> > > > > free form. One approach Mario has mentioned was to audit the
> > > > > user space WMI METHOD calls in the kernel platform drivers
> > > > > and reject those calls with arguments matching those issued
> > > > > by the kernel driver. This is likely to be complex and error
> > > > > prone in my opinion. However, I have not yet thought of
> > > > > another means to meet the requirement of having disjoint
> > > > > feature sets for userspace and kernel space via a mechanism
> > > > > that was effectively designed to be used solely from user
> > > > > space with vendor defined method signatures.
> > > > > 
> > > > > Next step is to look at just how complex it would be to audit
> > > > > the method calls the kernel currently uses.
> > > > 
> > > > I'm wondering whether it's really worth it.  We already allow
> > > > doing darned near anything using dcdbas.  Maybe the world
> > > > won't end if we expose a complete-ish ioctl interface to WMI.
> > 
> > I guess the world wouldn't end then (it has not ended for far more
> > serious 

Re: RFC: WMI Enhancements

[Pali Rohár]

On Tuesday 18 April 2017 18:33:25 Darren Hart wrote:
> On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
> > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart
> > > >  wrote:
> > > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki
> > > > > wrote:
> > > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > > > >> > Hi All,
> > > > >> > 
> > > > >> > There are a few parallel efforts involving the Windows
> > > > >> > Management Instrumentation (WMI)[1] and dependent/related
> > > > >> > drivers. I'd like to have a round of discussion among
> > > > >> > those of you that have been involved in this space before
> > > > >> > we decide on a direction.
> > > > >> > 
> > > > >> > The WMI support in the kernel today fairly narrowly
> > > > >> > supports a handful of systems. Andy L. has a
> > > > >> > work-in-progress series [2] which converts wmi into a
> > > > >> > platform device and a proper bus, providing devices for
> > > > >> > dependent drivers to bind to, and a mechanism for sibling
> > > > >> > devices to communicate with each other. I've reviewed the
> > > > >> > series and feel like the approach is sound, I plan to
> > > > >> > carry this series forward and merge it (with Andy L's
> > > > >> > permission).
> > > > >> > 
> > > > >> > Are there any objections to this?
> > > > >> > 
> > > > >> > In Windows, applications interact with WMI more or less
> > > > >> > directly. We don't do this in Linux currently, although
> > > > >> > it has been discussed in the past [3]. Some vendors will
> > > > >> > work around this by performing SMI/SMM, which is
> > > > >> > inefficient at best. Exposing WMI methods to userspace
> > > > >> > would bring parity to WMI for Linux and Windows.
> > > > >> > 
> > > > >> > There are two principal concerns I'd appreciate your
> > > > >> > thoughts on:
> > > > >> > 
> > > > >> > a) As an undiscoverable interface (you need to know the
> > > > >> > method signatures ahead of time), universally exposing
> > > > >> > every WMI "device" to userspace seems like "a bad idea"
> > > > >> > from a security and stability perspective. While access
> > > > >> > would certainly be privileged, it seems more prudent to
> > > > >> > make this exposure opt-in. We also handle some of this
> > > > >> > with kernel drivers and exposing those "devices" to
> > > > >> > userspace would enable userspace and the kernel to fight
> > > > >> > over control. So - if we expose WMI devices to userspace,
> > > > >> > I believe this should be done on a case by case basis,
> > > > >> > opting in, and not by default as part of the WMI driver
> > > > >> > (although it can provide the mechanism for a sub-driver
> > > > >> > to use), and possibly a devmode to do so by default.
> > > > >> 
> > > > >> A couple of loose thoughts here.
> > > > >> 
> > > > >> In principle there could be a "generic default WMI driver"
> > > > >> or similar that would "claim" all WMI "devices" that have
> > > > >> not been "claimed" by anyone else and would simply expose
> > > > >> them to user space somehow (e.g. using a chardev
> > > > >> interface).
> > > > >> 
> > > > >> Then, depending on how that thing is implemented, opt-in etc
> > > > >> should be possible too.
> > > > > 
> > > > > I think we agree this would be an ideal approach.
> > > > > 
> > > > > As we look into this more, it is becoming clear that the
> > > > > necessary functionality is not nicely divided into GUIDs for
> > > > > what is necessary in userspace and what is handled in the
> > > > > kernel. A single WMI METHOD GUID may be needed by userspace
> > > > > for certain functionality, while the kernel drivers may use
> > > > > it for something else.
> > > > > 
> > > > > :-(
> > > > > 
> > > > > The input to a WMI method is just a buffer, so it is very
> > > > > free form. One approach Mario has mentioned was to audit the
> > > > > user space WMI METHOD calls in the kernel platform drivers
> > > > > and reject those calls with arguments matching those issued
> > > > > by the kernel driver. This is likely to be complex and error
> > > > > prone in my opinion. However, I have not yet thought of
> > > > > another means to meet the requirement of having disjoint
> > > > > feature sets for userspace and kernel space via a mechanism
> > > > > that was effectively designed to be used solely from user
> > > > > space with vendor defined method signatures.
> > > > > 
> > > > > Next step is to look at just how complex it would be to audit
> > > > > the method calls the kernel currently uses.
> > > > 
> > > > I'm wondering whether it's really worth it.  We already allow
> > > > doing darned near anything using dcdbas.  Maybe the world
> > > > won't end if we expose a complete-ish ioctl interface to WMI.
> > 
> > I guess the world wouldn't end then (it has not ended for far more
> > serious reasons so far after 

Re: RFC: WMI Enhancements

[Darren Hart]

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

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

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

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

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

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

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

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

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

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

Re: RFC: WMI Enhancements

[Darren Hart]

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

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

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

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

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

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

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

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

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

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

Re: RFC: WMI Enhancements

[Darren Hart]

On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
> On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart  wrote:
> > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
> > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > > >> > Hi All,
> > > >> >
> > > >> > There are a few parallel efforts involving the Windows Management
> > > >> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to 
> > > >> > have a round of
> > > >> > discussion among those of you that have been involved in this space 
> > > >> > before we
> > > >> > decide on a direction.
> > > >> >
> > > >> > The WMI support in the kernel today fairly narrowly supports a 
> > > >> > handful of
> > > >> > systems. Andy L. has a work-in-progress series [2] which converts 
> > > >> > wmi into a
> > > >> > platform device and a proper bus, providing devices for dependent 
> > > >> > drivers to
> > > >> > bind to, and a mechanism for sibling devices to communicate with 
> > > >> > each other.
> > > >> > I've reviewed the series and feel like the approach is sound, I plan 
> > > >> > to carry
> > > >> > this series forward and merge it (with Andy L's permission).
> > > >> >
> > > >> > Are there any objections to this?
> > > >> >
> > > >> > In Windows, applications interact with WMI more or less directly. We 
> > > >> > don't do
> > > >> > this in Linux currently, although it has been discussed in the past 
> > > >> > [3]. Some
> > > >> > vendors will work around this by performing SMI/SMM, which is 
> > > >> > inefficient at
> > > >> > best. Exposing WMI methods to userspace would bring parity to WMI 
> > > >> > for Linux and
> > > >> > Windows.
> > > >> >
> > > >> > There are two principal concerns I'd appreciate your thoughts on:
> > > >> >
> > > >> > a) As an undiscoverable interface (you need to know the method 
> > > >> > signatures ahead
> > > >> > of time), universally exposing every WMI "device" to userspace seems 
> > > >> > like "a bad
> > > >> > idea" from a security and stability perspective. While access would 
> > > >> > certainly be
> > > >> > privileged, it seems more prudent to make this exposure opt-in. We 
> > > >> > also handle
> > > >> > some of this with kernel drivers and exposing those "devices" to 
> > > >> > userspace would
> > > >> > enable userspace and the kernel to fight over control. So - if we 
> > > >> > expose WMI
> > > >> > devices to userspace, I believe this should be done on a case by 
> > > >> > case basis,
> > > >> > opting in, and not by default as part of the WMI driver (although it 
> > > >> > can provide
> > > >> > the mechanism for a sub-driver to use), and possibly a devmode to do 
> > > >> > so by
> > > >> > default.
> > > >>
> > > >> A couple of loose thoughts here.
> > > >>
> > > >> In principle there could be a "generic default WMI driver" or similar 
> > > >> that would
> > > >> "claim" all WMI "devices" that have not been "claimed" by anyone else 
> > > >> and would
> > > >> simply expose them to user space somehow (e.g. using a chardev 
> > > >> interface).
> > > >>
> > > >> Then, depending on how that thing is implemented, opt-in etc should be 
> > > >> possible
> > > >> too.
> > > >>
> > > >
> > > > I think we agree this would be an ideal approach.
> > > >
> > > > As we look into this more, it is becoming clear that the necessary 
> > > > functionality
> > > > is not nicely divided into GUIDs for what is necessary in userspace and 
> > > > what is
> > > > handled in the kernel. A single WMI METHOD GUID may be needed by 
> > > > userspace for
> > > > certain functionality, while the kernel drivers may use it for 
> > > > something else.
> > > >
> > > > :-(
> > > >
> > > > The input to a WMI method is just a buffer, so it is very free form. One
> > > > approach Mario has mentioned was to audit the user space WMI METHOD 
> > > > calls in the
> > > > kernel platform drivers and reject those calls with arguments matching 
> > > > those
> > > > issued by the kernel driver. This is likely to be complex and error 
> > > > prone in my
> > > > opinion. However, I have not yet thought of another means to meet the
> > > > requirement of having disjoint feature sets for userspace and kernel 
> > > > space via a
> > > > mechanism that was effectively designed to be used solely from user 
> > > > space with
> > > > vendor defined method signatures.
> > > >
> > > > Next step is to look at just how complex it would be to audit the 
> > > > method calls
> > > > the kernel currently uses.
> > > 
> > > I'm wondering whether it's really worth it.  We already allow doing
> > > darned near anything using dcdbas.  Maybe the world won't end if we
> > > expose a complete-ish ioctl interface to WMI.
> 
> I guess the world wouldn't end then (it has not ended for far more serious
> reasons so far after all), but this 

Re: RFC: WMI Enhancements

[Darren Hart]

On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote:
> On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart  wrote:
> > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
> > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > > >> > Hi All,
> > > >> >
> > > >> > There are a few parallel efforts involving the Windows Management
> > > >> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to 
> > > >> > have a round of
> > > >> > discussion among those of you that have been involved in this space 
> > > >> > before we
> > > >> > decide on a direction.
> > > >> >
> > > >> > The WMI support in the kernel today fairly narrowly supports a 
> > > >> > handful of
> > > >> > systems. Andy L. has a work-in-progress series [2] which converts 
> > > >> > wmi into a
> > > >> > platform device and a proper bus, providing devices for dependent 
> > > >> > drivers to
> > > >> > bind to, and a mechanism for sibling devices to communicate with 
> > > >> > each other.
> > > >> > I've reviewed the series and feel like the approach is sound, I plan 
> > > >> > to carry
> > > >> > this series forward and merge it (with Andy L's permission).
> > > >> >
> > > >> > Are there any objections to this?
> > > >> >
> > > >> > In Windows, applications interact with WMI more or less directly. We 
> > > >> > don't do
> > > >> > this in Linux currently, although it has been discussed in the past 
> > > >> > [3]. Some
> > > >> > vendors will work around this by performing SMI/SMM, which is 
> > > >> > inefficient at
> > > >> > best. Exposing WMI methods to userspace would bring parity to WMI 
> > > >> > for Linux and
> > > >> > Windows.
> > > >> >
> > > >> > There are two principal concerns I'd appreciate your thoughts on:
> > > >> >
> > > >> > a) As an undiscoverable interface (you need to know the method 
> > > >> > signatures ahead
> > > >> > of time), universally exposing every WMI "device" to userspace seems 
> > > >> > like "a bad
> > > >> > idea" from a security and stability perspective. While access would 
> > > >> > certainly be
> > > >> > privileged, it seems more prudent to make this exposure opt-in. We 
> > > >> > also handle
> > > >> > some of this with kernel drivers and exposing those "devices" to 
> > > >> > userspace would
> > > >> > enable userspace and the kernel to fight over control. So - if we 
> > > >> > expose WMI
> > > >> > devices to userspace, I believe this should be done on a case by 
> > > >> > case basis,
> > > >> > opting in, and not by default as part of the WMI driver (although it 
> > > >> > can provide
> > > >> > the mechanism for a sub-driver to use), and possibly a devmode to do 
> > > >> > so by
> > > >> > default.
> > > >>
> > > >> A couple of loose thoughts here.
> > > >>
> > > >> In principle there could be a "generic default WMI driver" or similar 
> > > >> that would
> > > >> "claim" all WMI "devices" that have not been "claimed" by anyone else 
> > > >> and would
> > > >> simply expose them to user space somehow (e.g. using a chardev 
> > > >> interface).
> > > >>
> > > >> Then, depending on how that thing is implemented, opt-in etc should be 
> > > >> possible
> > > >> too.
> > > >>
> > > >
> > > > I think we agree this would be an ideal approach.
> > > >
> > > > As we look into this more, it is becoming clear that the necessary 
> > > > functionality
> > > > is not nicely divided into GUIDs for what is necessary in userspace and 
> > > > what is
> > > > handled in the kernel. A single WMI METHOD GUID may be needed by 
> > > > userspace for
> > > > certain functionality, while the kernel drivers may use it for 
> > > > something else.
> > > >
> > > > :-(
> > > >
> > > > The input to a WMI method is just a buffer, so it is very free form. One
> > > > approach Mario has mentioned was to audit the user space WMI METHOD 
> > > > calls in the
> > > > kernel platform drivers and reject those calls with arguments matching 
> > > > those
> > > > issued by the kernel driver. This is likely to be complex and error 
> > > > prone in my
> > > > opinion. However, I have not yet thought of another means to meet the
> > > > requirement of having disjoint feature sets for userspace and kernel 
> > > > space via a
> > > > mechanism that was effectively designed to be used solely from user 
> > > > space with
> > > > vendor defined method signatures.
> > > >
> > > > Next step is to look at just how complex it would be to audit the 
> > > > method calls
> > > > the kernel currently uses.
> > > 
> > > I'm wondering whether it's really worth it.  We already allow doing
> > > darned near anything using dcdbas.  Maybe the world won't end if we
> > > expose a complete-ish ioctl interface to WMI.
> 
> I guess the world wouldn't end then (it has not ended for far more serious
> reasons so far after all), but this also doesn't feel 

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

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

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

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

Re: RFC: WMI Enhancements

[Rafael J. Wysocki]

On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart  wrote:
> > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
> > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > >> > Hi All,
> > >> >
> > >> > There are a few parallel efforts involving the Windows Management
> > >> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to 
> > >> > have a round of
> > >> > discussion among those of you that have been involved in this space 
> > >> > before we
> > >> > decide on a direction.
> > >> >
> > >> > The WMI support in the kernel today fairly narrowly supports a handful 
> > >> > of
> > >> > systems. Andy L. has a work-in-progress series [2] which converts wmi 
> > >> > into a
> > >> > platform device and a proper bus, providing devices for dependent 
> > >> > drivers to
> > >> > bind to, and a mechanism for sibling devices to communicate with each 
> > >> > other.
> > >> > I've reviewed the series and feel like the approach is sound, I plan 
> > >> > to carry
> > >> > this series forward and merge it (with Andy L's permission).
> > >> >
> > >> > Are there any objections to this?
> > >> >
> > >> > In Windows, applications interact with WMI more or less directly. We 
> > >> > don't do
> > >> > this in Linux currently, although it has been discussed in the past 
> > >> > [3]. Some
> > >> > vendors will work around this by performing SMI/SMM, which is 
> > >> > inefficient at
> > >> > best. Exposing WMI methods to userspace would bring parity to WMI for 
> > >> > Linux and
> > >> > Windows.
> > >> >
> > >> > There are two principal concerns I'd appreciate your thoughts on:
> > >> >
> > >> > a) As an undiscoverable interface (you need to know the method 
> > >> > signatures ahead
> > >> > of time), universally exposing every WMI "device" to userspace seems 
> > >> > like "a bad
> > >> > idea" from a security and stability perspective. While access would 
> > >> > certainly be
> > >> > privileged, it seems more prudent to make this exposure opt-in. We 
> > >> > also handle
> > >> > some of this with kernel drivers and exposing those "devices" to 
> > >> > userspace would
> > >> > enable userspace and the kernel to fight over control. So - if we 
> > >> > expose WMI
> > >> > devices to userspace, I believe this should be done on a case by case 
> > >> > basis,
> > >> > opting in, and not by default as part of the WMI driver (although it 
> > >> > can provide
> > >> > the mechanism for a sub-driver to use), and possibly a devmode to do 
> > >> > so by
> > >> > default.
> > >>
> > >> A couple of loose thoughts here.
> > >>
> > >> In principle there could be a "generic default WMI driver" or similar 
> > >> that would
> > >> "claim" all WMI "devices" that have not been "claimed" by anyone else 
> > >> and would
> > >> simply expose them to user space somehow (e.g. using a chardev 
> > >> interface).
> > >>
> > >> Then, depending on how that thing is implemented, opt-in etc should be 
> > >> possible
> > >> too.
> > >>
> > >
> > > I think we agree this would be an ideal approach.
> > >
> > > As we look into this more, it is becoming clear that the necessary 
> > > functionality
> > > is not nicely divided into GUIDs for what is necessary in userspace and 
> > > what is
> > > handled in the kernel. A single WMI METHOD GUID may be needed by 
> > > userspace for
> > > certain functionality, while the kernel drivers may use it for something 
> > > else.
> > >
> > > :-(
> > >
> > > The input to a WMI method is just a buffer, so it is very free form. One
> > > approach Mario has mentioned was to audit the user space WMI METHOD calls 
> > > in the
> > > kernel platform drivers and reject those calls with arguments matching 
> > > those
> > > issued by the kernel driver. This is likely to be complex and error prone 
> > > in my
> > > opinion. However, I have not yet thought of another means to meet the
> > > requirement of having disjoint feature sets for userspace and kernel 
> > > space via a
> > > mechanism that was effectively designed to be used solely from user space 
> > > with
> > > vendor defined method signatures.
> > >
> > > Next step is to look at just how complex it would be to audit the method 
> > > calls
> > > the kernel currently uses.
> > 
> > I'm wondering whether it's really worth it.  We already allow doing
> > darned near anything using dcdbas.  Maybe the world won't end if we
> > expose a complete-ish ioctl interface to WMI.

I guess the world wouldn't end then (it has not ended for far more serious
reasons so far after all), but this also doesn't feel entirely right.

For one, if something is used inside of the kernel (by drivers etc), then
allowing user space to use the same thing directly is a recipe for unsupportable
mess IMO.

> > Also, dcdbas is, to put it mildly, a bit ridiculous.  It seems to be a
> > seriously 

Re: RFC: WMI Enhancements

[Rafael J. Wysocki]

On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote:
> On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart  wrote:
> > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
> > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > >> > Hi All,
> > >> >
> > >> > There are a few parallel efforts involving the Windows Management
> > >> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to 
> > >> > have a round of
> > >> > discussion among those of you that have been involved in this space 
> > >> > before we
> > >> > decide on a direction.
> > >> >
> > >> > The WMI support in the kernel today fairly narrowly supports a handful 
> > >> > of
> > >> > systems. Andy L. has a work-in-progress series [2] which converts wmi 
> > >> > into a
> > >> > platform device and a proper bus, providing devices for dependent 
> > >> > drivers to
> > >> > bind to, and a mechanism for sibling devices to communicate with each 
> > >> > other.
> > >> > I've reviewed the series and feel like the approach is sound, I plan 
> > >> > to carry
> > >> > this series forward and merge it (with Andy L's permission).
> > >> >
> > >> > Are there any objections to this?
> > >> >
> > >> > In Windows, applications interact with WMI more or less directly. We 
> > >> > don't do
> > >> > this in Linux currently, although it has been discussed in the past 
> > >> > [3]. Some
> > >> > vendors will work around this by performing SMI/SMM, which is 
> > >> > inefficient at
> > >> > best. Exposing WMI methods to userspace would bring parity to WMI for 
> > >> > Linux and
> > >> > Windows.
> > >> >
> > >> > There are two principal concerns I'd appreciate your thoughts on:
> > >> >
> > >> > a) As an undiscoverable interface (you need to know the method 
> > >> > signatures ahead
> > >> > of time), universally exposing every WMI "device" to userspace seems 
> > >> > like "a bad
> > >> > idea" from a security and stability perspective. While access would 
> > >> > certainly be
> > >> > privileged, it seems more prudent to make this exposure opt-in. We 
> > >> > also handle
> > >> > some of this with kernel drivers and exposing those "devices" to 
> > >> > userspace would
> > >> > enable userspace and the kernel to fight over control. So - if we 
> > >> > expose WMI
> > >> > devices to userspace, I believe this should be done on a case by case 
> > >> > basis,
> > >> > opting in, and not by default as part of the WMI driver (although it 
> > >> > can provide
> > >> > the mechanism for a sub-driver to use), and possibly a devmode to do 
> > >> > so by
> > >> > default.
> > >>
> > >> A couple of loose thoughts here.
> > >>
> > >> In principle there could be a "generic default WMI driver" or similar 
> > >> that would
> > >> "claim" all WMI "devices" that have not been "claimed" by anyone else 
> > >> and would
> > >> simply expose them to user space somehow (e.g. using a chardev 
> > >> interface).
> > >>
> > >> Then, depending on how that thing is implemented, opt-in etc should be 
> > >> possible
> > >> too.
> > >>
> > >
> > > I think we agree this would be an ideal approach.
> > >
> > > As we look into this more, it is becoming clear that the necessary 
> > > functionality
> > > is not nicely divided into GUIDs for what is necessary in userspace and 
> > > what is
> > > handled in the kernel. A single WMI METHOD GUID may be needed by 
> > > userspace for
> > > certain functionality, while the kernel drivers may use it for something 
> > > else.
> > >
> > > :-(
> > >
> > > The input to a WMI method is just a buffer, so it is very free form. One
> > > approach Mario has mentioned was to audit the user space WMI METHOD calls 
> > > in the
> > > kernel platform drivers and reject those calls with arguments matching 
> > > those
> > > issued by the kernel driver. This is likely to be complex and error prone 
> > > in my
> > > opinion. However, I have not yet thought of another means to meet the
> > > requirement of having disjoint feature sets for userspace and kernel 
> > > space via a
> > > mechanism that was effectively designed to be used solely from user space 
> > > with
> > > vendor defined method signatures.
> > >
> > > Next step is to look at just how complex it would be to audit the method 
> > > calls
> > > the kernel currently uses.
> > 
> > I'm wondering whether it's really worth it.  We already allow doing
> > darned near anything using dcdbas.  Maybe the world won't end if we
> > expose a complete-ish ioctl interface to WMI.

I guess the world wouldn't end then (it has not ended for far more serious
reasons so far after all), but this also doesn't feel entirely right.

For one, if something is used inside of the kernel (by drivers etc), then
allowing user space to use the same thing directly is a recipe for unsupportable
mess IMO.

> > Also, dcdbas is, to put it mildly, a bit ridiculous.  It seems to be a
> > seriously awkward sysfs 

Re: RFC: WMI Enhancements

[Pali Rohár]

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

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

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

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

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

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

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

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

Re: RFC: WMI Enhancements

[Pali Rohár]

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

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

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

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

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

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

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

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

Re: RFC: WMI Enhancements

[Andy Shevchenko]

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

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

-- 
Andy Shevchenko 
Intel Finland Oy

Re: RFC: WMI Enhancements

[Andy Shevchenko]

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

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

-- 
Andy Shevchenko 
Intel Finland Oy

Re: RFC: WMI Enhancements

[Darren Hart]

On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart  wrote:
> > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
> >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> >> > Hi All,
> >> >
> >> > There are a few parallel efforts involving the Windows Management
> >> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have 
> >> > a round of
> >> > discussion among those of you that have been involved in this space 
> >> > before we
> >> > decide on a direction.
> >> >
> >> > The WMI support in the kernel today fairly narrowly supports a handful of
> >> > systems. Andy L. has a work-in-progress series [2] which converts wmi 
> >> > into a
> >> > platform device and a proper bus, providing devices for dependent 
> >> > drivers to
> >> > bind to, and a mechanism for sibling devices to communicate with each 
> >> > other.
> >> > I've reviewed the series and feel like the approach is sound, I plan to 
> >> > carry
> >> > this series forward and merge it (with Andy L's permission).
> >> >
> >> > Are there any objections to this?
> >> >
> >> > In Windows, applications interact with WMI more or less directly. We 
> >> > don't do
> >> > this in Linux currently, although it has been discussed in the past [3]. 
> >> > Some
> >> > vendors will work around this by performing SMI/SMM, which is 
> >> > inefficient at
> >> > best. Exposing WMI methods to userspace would bring parity to WMI for 
> >> > Linux and
> >> > Windows.
> >> >
> >> > There are two principal concerns I'd appreciate your thoughts on:
> >> >
> >> > a) As an undiscoverable interface (you need to know the method 
> >> > signatures ahead
> >> > of time), universally exposing every WMI "device" to userspace seems 
> >> > like "a bad
> >> > idea" from a security and stability perspective. While access would 
> >> > certainly be
> >> > privileged, it seems more prudent to make this exposure opt-in. We also 
> >> > handle
> >> > some of this with kernel drivers and exposing those "devices" to 
> >> > userspace would
> >> > enable userspace and the kernel to fight over control. So - if we expose 
> >> > WMI
> >> > devices to userspace, I believe this should be done on a case by case 
> >> > basis,
> >> > opting in, and not by default as part of the WMI driver (although it can 
> >> > provide
> >> > the mechanism for a sub-driver to use), and possibly a devmode to do so 
> >> > by
> >> > default.
> >>
> >> A couple of loose thoughts here.
> >>
> >> In principle there could be a "generic default WMI driver" or similar that 
> >> would
> >> "claim" all WMI "devices" that have not been "claimed" by anyone else and 
> >> would
> >> simply expose them to user space somehow (e.g. using a chardev interface).
> >>
> >> Then, depending on how that thing is implemented, opt-in etc should be 
> >> possible
> >> too.
> >>
> >
> > I think we agree this would be an ideal approach.
> >
> > As we look into this more, it is becoming clear that the necessary 
> > functionality
> > is not nicely divided into GUIDs for what is necessary in userspace and 
> > what is
> > handled in the kernel. A single WMI METHOD GUID may be needed by userspace 
> > for
> > certain functionality, while the kernel drivers may use it for something 
> > else.
> >
> > :-(
> >
> > The input to a WMI method is just a buffer, so it is very free form. One
> > approach Mario has mentioned was to audit the user space WMI METHOD calls 
> > in the
> > kernel platform drivers and reject those calls with arguments matching those
> > issued by the kernel driver. This is likely to be complex and error prone 
> > in my
> > opinion. However, I have not yet thought of another means to meet the
> > requirement of having disjoint feature sets for userspace and kernel space 
> > via a
> > mechanism that was effectively designed to be used solely from user space 
> > with
> > vendor defined method signatures.
> >
> > Next step is to look at just how complex it would be to audit the method 
> > calls
> > the kernel currently uses.
> 
> I'm wondering whether it's really worth it.  We already allow doing
> darned near anything using dcdbas.  Maybe the world won't end if we
> expose a complete-ish ioctl interface to WMI.
> 
> Also, dcdbas is, to put it mildly, a bit ridiculous.  It seems to be a
> seriously awkward sysfs interface that allows you to, drumroll please,
> issue outb and inb instructions.  It doesn't even check that it's
> running on a Dell system.  It might be nice to deprecate it some day
> in favor of a real interface.  I'd consider a low-level WMI ioctl
> interface to be a vast improvement.
> 

I've been reluctantly arriving here as well. Given that every WMI interface will
be vendor specific, and non-discoverable, it seems unlikely developers will
eagerly duplicate kernel functionality in user-space. And if they do, it will
affect very few platforms.

I still think it makes sense 

Re: RFC: WMI Enhancements

[Darren Hart]

On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart  wrote:
> > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
> >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> >> > Hi All,
> >> >
> >> > There are a few parallel efforts involving the Windows Management
> >> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have 
> >> > a round of
> >> > discussion among those of you that have been involved in this space 
> >> > before we
> >> > decide on a direction.
> >> >
> >> > The WMI support in the kernel today fairly narrowly supports a handful of
> >> > systems. Andy L. has a work-in-progress series [2] which converts wmi 
> >> > into a
> >> > platform device and a proper bus, providing devices for dependent 
> >> > drivers to
> >> > bind to, and a mechanism for sibling devices to communicate with each 
> >> > other.
> >> > I've reviewed the series and feel like the approach is sound, I plan to 
> >> > carry
> >> > this series forward and merge it (with Andy L's permission).
> >> >
> >> > Are there any objections to this?
> >> >
> >> > In Windows, applications interact with WMI more or less directly. We 
> >> > don't do
> >> > this in Linux currently, although it has been discussed in the past [3]. 
> >> > Some
> >> > vendors will work around this by performing SMI/SMM, which is 
> >> > inefficient at
> >> > best. Exposing WMI methods to userspace would bring parity to WMI for 
> >> > Linux and
> >> > Windows.
> >> >
> >> > There are two principal concerns I'd appreciate your thoughts on:
> >> >
> >> > a) As an undiscoverable interface (you need to know the method 
> >> > signatures ahead
> >> > of time), universally exposing every WMI "device" to userspace seems 
> >> > like "a bad
> >> > idea" from a security and stability perspective. While access would 
> >> > certainly be
> >> > privileged, it seems more prudent to make this exposure opt-in. We also 
> >> > handle
> >> > some of this with kernel drivers and exposing those "devices" to 
> >> > userspace would
> >> > enable userspace and the kernel to fight over control. So - if we expose 
> >> > WMI
> >> > devices to userspace, I believe this should be done on a case by case 
> >> > basis,
> >> > opting in, and not by default as part of the WMI driver (although it can 
> >> > provide
> >> > the mechanism for a sub-driver to use), and possibly a devmode to do so 
> >> > by
> >> > default.
> >>
> >> A couple of loose thoughts here.
> >>
> >> In principle there could be a "generic default WMI driver" or similar that 
> >> would
> >> "claim" all WMI "devices" that have not been "claimed" by anyone else and 
> >> would
> >> simply expose them to user space somehow (e.g. using a chardev interface).
> >>
> >> Then, depending on how that thing is implemented, opt-in etc should be 
> >> possible
> >> too.
> >>
> >
> > I think we agree this would be an ideal approach.
> >
> > As we look into this more, it is becoming clear that the necessary 
> > functionality
> > is not nicely divided into GUIDs for what is necessary in userspace and 
> > what is
> > handled in the kernel. A single WMI METHOD GUID may be needed by userspace 
> > for
> > certain functionality, while the kernel drivers may use it for something 
> > else.
> >
> > :-(
> >
> > The input to a WMI method is just a buffer, so it is very free form. One
> > approach Mario has mentioned was to audit the user space WMI METHOD calls 
> > in the
> > kernel platform drivers and reject those calls with arguments matching those
> > issued by the kernel driver. This is likely to be complex and error prone 
> > in my
> > opinion. However, I have not yet thought of another means to meet the
> > requirement of having disjoint feature sets for userspace and kernel space 
> > via a
> > mechanism that was effectively designed to be used solely from user space 
> > with
> > vendor defined method signatures.
> >
> > Next step is to look at just how complex it would be to audit the method 
> > calls
> > the kernel currently uses.
> 
> I'm wondering whether it's really worth it.  We already allow doing
> darned near anything using dcdbas.  Maybe the world won't end if we
> expose a complete-ish ioctl interface to WMI.
> 
> Also, dcdbas is, to put it mildly, a bit ridiculous.  It seems to be a
> seriously awkward sysfs interface that allows you to, drumroll please,
> issue outb and inb instructions.  It doesn't even check that it's
> running on a Dell system.  It might be nice to deprecate it some day
> in favor of a real interface.  I'd consider a low-level WMI ioctl
> interface to be a vast improvement.
> 

I've been reluctantly arriving here as well. Given that every WMI interface will
be vendor specific, and non-discoverable, it seems unlikely developers will
eagerly duplicate kernel functionality in user-space. And if they do, it will
affect very few platforms.

I still think it makes sense to only expose a WMI 

Re: RFC: WMI Enhancements

[Andy Lutomirski]

On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart  wrote:
> On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
>> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
>> > Hi All,
>> >
>> > There are a few parallel efforts involving the Windows Management
>> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have a 
>> > round of
>> > discussion among those of you that have been involved in this space before 
>> > we
>> > decide on a direction.
>> >
>> > The WMI support in the kernel today fairly narrowly supports a handful of
>> > systems. Andy L. has a work-in-progress series [2] which converts wmi into 
>> > a
>> > platform device and a proper bus, providing devices for dependent drivers 
>> > to
>> > bind to, and a mechanism for sibling devices to communicate with each 
>> > other.
>> > I've reviewed the series and feel like the approach is sound, I plan to 
>> > carry
>> > this series forward and merge it (with Andy L's permission).
>> >
>> > Are there any objections to this?
>> >
>> > In Windows, applications interact with WMI more or less directly. We don't 
>> > do
>> > this in Linux currently, although it has been discussed in the past [3]. 
>> > Some
>> > vendors will work around this by performing SMI/SMM, which is inefficient 
>> > at
>> > best. Exposing WMI methods to userspace would bring parity to WMI for 
>> > Linux and
>> > Windows.
>> >
>> > There are two principal concerns I'd appreciate your thoughts on:
>> >
>> > a) As an undiscoverable interface (you need to know the method signatures 
>> > ahead
>> > of time), universally exposing every WMI "device" to userspace seems like 
>> > "a bad
>> > idea" from a security and stability perspective. While access would 
>> > certainly be
>> > privileged, it seems more prudent to make this exposure opt-in. We also 
>> > handle
>> > some of this with kernel drivers and exposing those "devices" to userspace 
>> > would
>> > enable userspace and the kernel to fight over control. So - if we expose 
>> > WMI
>> > devices to userspace, I believe this should be done on a case by case 
>> > basis,
>> > opting in, and not by default as part of the WMI driver (although it can 
>> > provide
>> > the mechanism for a sub-driver to use), and possibly a devmode to do so by
>> > default.
>>
>> A couple of loose thoughts here.
>>
>> In principle there could be a "generic default WMI driver" or similar that 
>> would
>> "claim" all WMI "devices" that have not been "claimed" by anyone else and 
>> would
>> simply expose them to user space somehow (e.g. using a chardev interface).
>>
>> Then, depending on how that thing is implemented, opt-in etc should be 
>> possible
>> too.
>>
>
> I think we agree this would be an ideal approach.
>
> As we look into this more, it is becoming clear that the necessary 
> functionality
> is not nicely divided into GUIDs for what is necessary in userspace and what 
> is
> handled in the kernel. A single WMI METHOD GUID may be needed by userspace for
> certain functionality, while the kernel drivers may use it for something else.
>
> :-(
>
> The input to a WMI method is just a buffer, so it is very free form. One
> approach Mario has mentioned was to audit the user space WMI METHOD calls in 
> the
> kernel platform drivers and reject those calls with arguments matching those
> issued by the kernel driver. This is likely to be complex and error prone in 
> my
> opinion. However, I have not yet thought of another means to meet the
> requirement of having disjoint feature sets for userspace and kernel space 
> via a
> mechanism that was effectively designed to be used solely from user space with
> vendor defined method signatures.
>
> Next step is to look at just how complex it would be to audit the method calls
> the kernel currently uses.

I'm wondering whether it's really worth it.  We already allow doing
darned near anything using dcdbas.  Maybe the world won't end if we
expose a complete-ish ioctl interface to WMI.

Also, dcdbas is, to put it mildly, a bit ridiculous.  It seems to be a
seriously awkward sysfs interface that allows you to, drumroll please,
issue outb and inb instructions.  It doesn't even check that it's
running on a Dell system.  It might be nice to deprecate it some day
in favor of a real interface.  I'd consider a low-level WMI ioctl
interface to be a vast improvement.

Re: RFC: WMI Enhancements

[Andy Lutomirski]

On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart  wrote:
> On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
>> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
>> > Hi All,
>> >
>> > There are a few parallel efforts involving the Windows Management
>> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have a 
>> > round of
>> > discussion among those of you that have been involved in this space before 
>> > we
>> > decide on a direction.
>> >
>> > The WMI support in the kernel today fairly narrowly supports a handful of
>> > systems. Andy L. has a work-in-progress series [2] which converts wmi into 
>> > a
>> > platform device and a proper bus, providing devices for dependent drivers 
>> > to
>> > bind to, and a mechanism for sibling devices to communicate with each 
>> > other.
>> > I've reviewed the series and feel like the approach is sound, I plan to 
>> > carry
>> > this series forward and merge it (with Andy L's permission).
>> >
>> > Are there any objections to this?
>> >
>> > In Windows, applications interact with WMI more or less directly. We don't 
>> > do
>> > this in Linux currently, although it has been discussed in the past [3]. 
>> > Some
>> > vendors will work around this by performing SMI/SMM, which is inefficient 
>> > at
>> > best. Exposing WMI methods to userspace would bring parity to WMI for 
>> > Linux and
>> > Windows.
>> >
>> > There are two principal concerns I'd appreciate your thoughts on:
>> >
>> > a) As an undiscoverable interface (you need to know the method signatures 
>> > ahead
>> > of time), universally exposing every WMI "device" to userspace seems like 
>> > "a bad
>> > idea" from a security and stability perspective. While access would 
>> > certainly be
>> > privileged, it seems more prudent to make this exposure opt-in. We also 
>> > handle
>> > some of this with kernel drivers and exposing those "devices" to userspace 
>> > would
>> > enable userspace and the kernel to fight over control. So - if we expose 
>> > WMI
>> > devices to userspace, I believe this should be done on a case by case 
>> > basis,
>> > opting in, and not by default as part of the WMI driver (although it can 
>> > provide
>> > the mechanism for a sub-driver to use), and possibly a devmode to do so by
>> > default.
>>
>> A couple of loose thoughts here.
>>
>> In principle there could be a "generic default WMI driver" or similar that 
>> would
>> "claim" all WMI "devices" that have not been "claimed" by anyone else and 
>> would
>> simply expose them to user space somehow (e.g. using a chardev interface).
>>
>> Then, depending on how that thing is implemented, opt-in etc should be 
>> possible
>> too.
>>
>
> I think we agree this would be an ideal approach.
>
> As we look into this more, it is becoming clear that the necessary 
> functionality
> is not nicely divided into GUIDs for what is necessary in userspace and what 
> is
> handled in the kernel. A single WMI METHOD GUID may be needed by userspace for
> certain functionality, while the kernel drivers may use it for something else.
>
> :-(
>
> The input to a WMI method is just a buffer, so it is very free form. One
> approach Mario has mentioned was to audit the user space WMI METHOD calls in 
> the
> kernel platform drivers and reject those calls with arguments matching those
> issued by the kernel driver. This is likely to be complex and error prone in 
> my
> opinion. However, I have not yet thought of another means to meet the
> requirement of having disjoint feature sets for userspace and kernel space 
> via a
> mechanism that was effectively designed to be used solely from user space with
> vendor defined method signatures.
>
> Next step is to look at just how complex it would be to audit the method calls
> the kernel currently uses.

I'm wondering whether it's really worth it.  We already allow doing
darned near anything using dcdbas.  Maybe the world won't end if we
expose a complete-ish ioctl interface to WMI.

Also, dcdbas is, to put it mildly, a bit ridiculous.  It seems to be a
seriously awkward sysfs interface that allows you to, drumroll please,
issue outb and inb instructions.  It doesn't even check that it's
running on a Dell system.  It might be nice to deprecate it some day
in favor of a real interface.  I'd consider a low-level WMI ioctl
interface to be a vast improvement.

Re: RFC: WMI Enhancements

[Darren Hart]

On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > Hi All,
> > 
> > There are a few parallel efforts involving the Windows Management
> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have a 
> > round of
> > discussion among those of you that have been involved in this space before 
> > we
> > decide on a direction.
> > 
> > The WMI support in the kernel today fairly narrowly supports a handful of
> > systems. Andy L. has a work-in-progress series [2] which converts wmi into a
> > platform device and a proper bus, providing devices for dependent drivers to
> > bind to, and a mechanism for sibling devices to communicate with each other.
> > I've reviewed the series and feel like the approach is sound, I plan to 
> > carry
> > this series forward and merge it (with Andy L's permission).
> > 
> > Are there any objections to this?
> > 
> > In Windows, applications interact with WMI more or less directly. We don't 
> > do
> > this in Linux currently, although it has been discussed in the past [3]. 
> > Some
> > vendors will work around this by performing SMI/SMM, which is inefficient at
> > best. Exposing WMI methods to userspace would bring parity to WMI for Linux 
> > and
> > Windows.
> > 
> > There are two principal concerns I'd appreciate your thoughts on:
> > 
> > a) As an undiscoverable interface (you need to know the method signatures 
> > ahead
> > of time), universally exposing every WMI "device" to userspace seems like 
> > "a bad
> > idea" from a security and stability perspective. While access would 
> > certainly be
> > privileged, it seems more prudent to make this exposure opt-in. We also 
> > handle
> > some of this with kernel drivers and exposing those "devices" to userspace 
> > would
> > enable userspace and the kernel to fight over control. So - if we expose WMI
> > devices to userspace, I believe this should be done on a case by case basis,
> > opting in, and not by default as part of the WMI driver (although it can 
> > provide
> > the mechanism for a sub-driver to use), and possibly a devmode to do so by
> > default.
> 
> A couple of loose thoughts here.
> 
> In principle there could be a "generic default WMI driver" or similar that 
> would
> "claim" all WMI "devices" that have not been "claimed" by anyone else and 
> would
> simply expose them to user space somehow (e.g. using a chardev interface).
> 
> Then, depending on how that thing is implemented, opt-in etc should be 
> possible
> too.
> 

I think we agree this would be an ideal approach.

As we look into this more, it is becoming clear that the necessary functionality
is not nicely divided into GUIDs for what is necessary in userspace and what is
handled in the kernel. A single WMI METHOD GUID may be needed by userspace for
certain functionality, while the kernel drivers may use it for something else.

:-(

The input to a WMI method is just a buffer, so it is very free form. One
approach Mario has mentioned was to audit the user space WMI METHOD calls in the
kernel platform drivers and reject those calls with arguments matching those
issued by the kernel driver. This is likely to be complex and error prone in my
opinion. However, I have not yet thought of another means to meet the
requirement of having disjoint feature sets for userspace and kernel space via a
mechanism that was effectively designed to be used solely from user space with
vendor defined method signatures.

Next step is to look at just how complex it would be to audit the method calls
the kernel currently uses.

-- 
Darren Hart
VMware Open Source Technology Center

Re: RFC: WMI Enhancements

[Darren Hart]

On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > Hi All,
> > 
> > There are a few parallel efforts involving the Windows Management
> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have a 
> > round of
> > discussion among those of you that have been involved in this space before 
> > we
> > decide on a direction.
> > 
> > The WMI support in the kernel today fairly narrowly supports a handful of
> > systems. Andy L. has a work-in-progress series [2] which converts wmi into a
> > platform device and a proper bus, providing devices for dependent drivers to
> > bind to, and a mechanism for sibling devices to communicate with each other.
> > I've reviewed the series and feel like the approach is sound, I plan to 
> > carry
> > this series forward and merge it (with Andy L's permission).
> > 
> > Are there any objections to this?
> > 
> > In Windows, applications interact with WMI more or less directly. We don't 
> > do
> > this in Linux currently, although it has been discussed in the past [3]. 
> > Some
> > vendors will work around this by performing SMI/SMM, which is inefficient at
> > best. Exposing WMI methods to userspace would bring parity to WMI for Linux 
> > and
> > Windows.
> > 
> > There are two principal concerns I'd appreciate your thoughts on:
> > 
> > a) As an undiscoverable interface (you need to know the method signatures 
> > ahead
> > of time), universally exposing every WMI "device" to userspace seems like 
> > "a bad
> > idea" from a security and stability perspective. While access would 
> > certainly be
> > privileged, it seems more prudent to make this exposure opt-in. We also 
> > handle
> > some of this with kernel drivers and exposing those "devices" to userspace 
> > would
> > enable userspace and the kernel to fight over control. So - if we expose WMI
> > devices to userspace, I believe this should be done on a case by case basis,
> > opting in, and not by default as part of the WMI driver (although it can 
> > provide
> > the mechanism for a sub-driver to use), and possibly a devmode to do so by
> > default.
> 
> A couple of loose thoughts here.
> 
> In principle there could be a "generic default WMI driver" or similar that 
> would
> "claim" all WMI "devices" that have not been "claimed" by anyone else and 
> would
> simply expose them to user space somehow (e.g. using a chardev interface).
> 
> Then, depending on how that thing is implemented, opt-in etc should be 
> possible
> too.
> 

I think we agree this would be an ideal approach.

As we look into this more, it is becoming clear that the necessary functionality
is not nicely divided into GUIDs for what is necessary in userspace and what is
handled in the kernel. A single WMI METHOD GUID may be needed by userspace for
certain functionality, while the kernel drivers may use it for something else.

:-(

The input to a WMI method is just a buffer, so it is very free form. One
approach Mario has mentioned was to audit the user space WMI METHOD calls in the
kernel platform drivers and reject those calls with arguments matching those
issued by the kernel driver. This is likely to be complex and error prone in my
opinion. However, I have not yet thought of another means to meet the
requirement of having disjoint feature sets for userspace and kernel space via a
mechanism that was effectively designed to be used solely from user space with
vendor defined method signatures.

Next step is to look at just how complex it would be to audit the method calls
the kernel currently uses.

-- 
Darren Hart
VMware Open Source Technology Center

Re: RFC: WMI Enhancements

[Rafael J. Wysocki]

On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> Hi All,
> 
> There are a few parallel efforts involving the Windows Management
> Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have a 
> round of
> discussion among those of you that have been involved in this space before we
> decide on a direction.
> 
> The WMI support in the kernel today fairly narrowly supports a handful of
> systems. Andy L. has a work-in-progress series [2] which converts wmi into a
> platform device and a proper bus, providing devices for dependent drivers to
> bind to, and a mechanism for sibling devices to communicate with each other.
> I've reviewed the series and feel like the approach is sound, I plan to carry
> this series forward and merge it (with Andy L's permission).
> 
> Are there any objections to this?
> 
> In Windows, applications interact with WMI more or less directly. We don't do
> this in Linux currently, although it has been discussed in the past [3]. Some
> vendors will work around this by performing SMI/SMM, which is inefficient at
> best. Exposing WMI methods to userspace would bring parity to WMI for Linux 
> and
> Windows.
> 
> There are two principal concerns I'd appreciate your thoughts on:
> 
> a) As an undiscoverable interface (you need to know the method signatures 
> ahead
> of time), universally exposing every WMI "device" to userspace seems like "a 
> bad
> idea" from a security and stability perspective. While access would certainly 
> be
> privileged, it seems more prudent to make this exposure opt-in. We also handle
> some of this with kernel drivers and exposing those "devices" to userspace 
> would
> enable userspace and the kernel to fight over control. So - if we expose WMI
> devices to userspace, I believe this should be done on a case by case basis,
> opting in, and not by default as part of the WMI driver (although it can 
> provide
> the mechanism for a sub-driver to use), and possibly a devmode to do so by
> default.

A couple of loose thoughts here.

In principle there could be a "generic default WMI driver" or similar that would
"claim" all WMI "devices" that have not been "claimed" by anyone else and would
simply expose them to user space somehow (e.g. using a chardev interface).

Then, depending on how that thing is implemented, opt-in etc should be possible
too.

Thanks,
Rafael

Re: RFC: WMI Enhancements

[Rafael J. Wysocki]

On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> Hi All,
> 
> There are a few parallel efforts involving the Windows Management
> Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have a 
> round of
> discussion among those of you that have been involved in this space before we
> decide on a direction.
> 
> The WMI support in the kernel today fairly narrowly supports a handful of
> systems. Andy L. has a work-in-progress series [2] which converts wmi into a
> platform device and a proper bus, providing devices for dependent drivers to
> bind to, and a mechanism for sibling devices to communicate with each other.
> I've reviewed the series and feel like the approach is sound, I plan to carry
> this series forward and merge it (with Andy L's permission).
> 
> Are there any objections to this?
> 
> In Windows, applications interact with WMI more or less directly. We don't do
> this in Linux currently, although it has been discussed in the past [3]. Some
> vendors will work around this by performing SMI/SMM, which is inefficient at
> best. Exposing WMI methods to userspace would bring parity to WMI for Linux 
> and
> Windows.
> 
> There are two principal concerns I'd appreciate your thoughts on:
> 
> a) As an undiscoverable interface (you need to know the method signatures 
> ahead
> of time), universally exposing every WMI "device" to userspace seems like "a 
> bad
> idea" from a security and stability perspective. While access would certainly 
> be
> privileged, it seems more prudent to make this exposure opt-in. We also handle
> some of this with kernel drivers and exposing those "devices" to userspace 
> would
> enable userspace and the kernel to fight over control. So - if we expose WMI
> devices to userspace, I believe this should be done on a case by case basis,
> opting in, and not by default as part of the WMI driver (although it can 
> provide
> the mechanism for a sub-driver to use), and possibly a devmode to do so by
> default.

A couple of loose thoughts here.

In principle there could be a "generic default WMI driver" or similar that would
"claim" all WMI "devices" that have not been "claimed" by anyone else and would
simply expose them to user space somehow (e.g. using a chardev interface).

Then, depending on how that thing is implemented, opt-in etc should be possible
too.

Thanks,
Rafael

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

Re: RFC: WMI Enhancements

[Darren Hart]

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

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

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

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

Re: RFC: WMI Enhancements

[Darren Hart]

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

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

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

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

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

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

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

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

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

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

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

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

RE: RFC: WMI Enhancements

[Mario.Limonciello]

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

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

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

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

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

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

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

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

Re: RFC: WMI Enhancements

[Darren Hart]

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

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

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

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

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

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

-- 
Darren Hart
VMware Open Source Technology Center

Re: RFC: WMI Enhancements

[Darren Hart]

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

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

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

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

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

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

-- 
Darren Hart
VMware Open Source Technology Center