Date:   Mon, 8 May 2017 15:36:31 +0000
From:   <Mario.Limonciello@...l.com>
To:     <dvhart@...radead.org>, <luto@...nel.org>
CC:     <pali.rohar@...il.com>, <rjw@...ysocki.net>, <len.brown@...el.com>,
        <corentin.chary@...il.com>, <andriy.shevchenko@...ux.intel.com>,
        <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <linux-pm@...r.kernel.org>
Subject: RE: RFC: WMI Enhancements

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@...radead.org]
> Sent: Monday, May 8, 2017 10:29 AM
> To: Andy Lutomirski <luto@...nel.org>
> Cc: Limonciello, Mario <Mario_Limonciello@...l.com>; Pali Rohár
> <pali.rohar@...il.com>; Rafael J. Wysocki <rjw@...ysocki.net>; Len Brown
> <len.brown@...el.com>; Corentin Chary <corentin.chary@...il.com>; Andy
> Shevchenko <andriy.shevchenko@...ux.intel.com>; linux-kernel@...r.kernel.org;
> platform-driver-x86@...r.kernel.org; linux-pm@...r.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Fri, May 05, 2017 at 06:25:08PM -0700, Andy Lutomirski wrote:
> > On Fri, May 5, 2017 at 5:51 PM,  <Mario.Limonciello@...l.com> wrote:
> > >> -----Original Message-----
> > >> From: Darren Hart [mailto:dvhart@...radead.org]
> > >> Sent: Friday, May 5, 2017 6:45 PM
> > >> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> > >> Cc: pali.rohar@...il.com; rjw@...ysocki.net; luto@...capital.net;
> > >> len.brown@...el.com; corentin.chary@...il.com; luto@...nel.org;
> > >> andriy.shevchenko@...ux.intel.com; linux-kernel@...r.kernel.org; platform-
> > >> driver-x86@...r.kernel.org; linux-pm@...r.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.

Powered by blists - more mailing lists