RE: [PATCH v4 12/14] platform/x86: wmi: create character devices when requested by drivers

[Mario.Limonciello]

> -----Original Message-----
> From: Greg KH [mailto:greg@xxxxxxxxx]
> Sent: Thursday, October 5, 2017 2:10 PM
> To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> Cc: dvhart@xxxxxxxxxxxxx; pali.rohar@xxxxxxxxx; andy.shevchenko@xxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; platform-driver-x86@xxxxxxxxxxxxxxx;
> luto@xxxxxxxxxx; quasisec@xxxxxxxxxx; rjw@xxxxxxxxxxxxx;
> mjg59@xxxxxxxxxx; hch@xxxxxx
> Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when
> requested by drivers
> 
> On Thu, Oct 05, 2017 at 07:03:24PM +0000, Mario.Limonciello@xxxxxxxx wrote:
> > > -----Original Message-----
> > > From: Greg KH [mailto:greg@xxxxxxxxx]
> > > Sent: Thursday, October 5, 2017 1:47 PM
> > > To: Darren Hart <dvhart@xxxxxxxxxxxxx>
> > > Cc: Pali Rohár <pali.rohar@xxxxxxxxx>; Limonciello, Mario
> > > <Mario_Limonciello@xxxxxxxx>; andy.shevchenko@xxxxxxxxx; linux-
> > > kernel@xxxxxxxxxxxxxxx; platform-driver-x86@xxxxxxxxxxxxxxx;
> luto@xxxxxxxxxx;
> > > quasisec@xxxxxxxxxx; rjw@xxxxxxxxxxxxx; mjg59@xxxxxxxxxx; hch@xxxxxx
> > > Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices
> when
> > > requested by drivers
> > >
> > > On Thu, Oct 05, 2017 at 10:39:25AM -0700, Darren Hart wrote:
> > > > > It does, thanks.  And as we now understand it (I'm guessing it had to be
> > > > > semi-understood in the older wmi drivers already), validating it
> > > > > properly seems to be the key for creating an interface that we "know" to
> > > > > be safe.
> > > > >
> > > >
> > > > We don't use the MOF data in any of the existing wmi drivers, because
> > > > they are all oddities which map to kernel managed subsystems (hotkeys,
> > > > LED control, RF Kill switches) rather than what WMI (Windows
> > > > Manageability Interface) was designed for. The intent of these patches
> > > > to enable that management aspect of the platform.
> > > >
> > > > This is the biggest hurdle for WMI support.
> > > >
> > > > WMI was designed to bypass the OS, and is used in consumer devices
> > > > intended to run Windows. This leads to an interface that is very vendor
> > > > specific and not consistently broken up into nice functional blocks.
> > > >
> > > > Vendors would like to use this interface in Linux as it is being used in
> > > > Windows. Specifically, they want to be able to have a generic system in
> > > > the kernel which allows the WMI mechanism to be used by userspace,
> > > > without the need to patch the kernel for every platform.
> > >
> > > And how _exactly_ is this interface exposed in Windows?  Is it ad-hoc
> > > with custom kernel drivers written by each vendor?  Or does the OS
> > > provide a "sane" interface for it?
> >
> > On Windows it's a driver-less solution.  Vendors don't do anything other
> > than provide the MOF (which describes how the data passed to ASL looks).
> 
> How do they "provide it"?

In that link I shared you can see there is a GUID that maps to the one that
has the binary MOF.  The MOF is compiled when the BIOS is built using
mofcomp.exe on Windows into a binary format.

> 
> > When Windows boots up, _WDG is parsed,
> 
> Who parses it, the Windows kernel?
> 
Presumably?  Wmiacpi.sys.  I believe it to be user side, but I don't know Windows
source code and where they draw the line.

> > the binary MOF is loaded into the WMI repository.
> 
> Who does the loading?  Where does the "WMI repository" live?

Windows OS does this.  Same wmiacpi.sys I believe.  The WMI repository is a
database that's on disk.  It doesn't just do these things, it contains MOF (managed
object format) for a bunch of stuff.  You can tweak way too many knobs with it.

It's store in "%windir%System32\Wbem\Repository"
There's more info about how it works here
https://technet.microsoft.com/en-us/library/cc753534.aspx

I do have a longer term vision for Linux that CIMOM tools will be able to parse
what the kernel shares in sysfs from the WMI bus and know how to work with 
these character devices.

My patch series is the first part of that, and there are still a lot of other steps.

> 
> > The MOF describes how named objects map to GUIDs which map to ASL.
> 
> So this all lives in kernelspace?
> 
> > From Powershell or from any application that uses WMI as admin you can
> > look up the root namespace and see all objects.
> 
> And what is the interface that powershell uses to get that information
> from the kerenel?

You query the WMI repository for available namespaces.  The stuff in the binary
MOF will have registered under a particular namespace.
When you look at that namespace, you can query classes within it.

Some of those classes will enumerate objects that you can read attributes.
If you're calling a method, you need to fill in the arguments as described in the
MOF.  You can query the namespace to tell what those arguments look like.

So going to my patch series, "dell-wmi-descriptor" would map out to a class
In the namespace.  You can query it to see what the size of the buffer looks
like and what the interface is.

The class that in Linux represents "dell-smbios-wmi" would map to another one.  
You can't enumerate it since It's not a data type, but you can look at what arguments
it takes and if you provide the arguments it expects you can call it and the OS
will pass it to the ASL and return the result.

It's not very different than what I proposed in my patch series.

> 
> > You can pass calls back
> > and forth.  There's all sorts of examples of it here:
> > https://msdn.microsoft.com/en-
> us/library/windows/hardware/dn614028(v=vs.85).aspx
> >
> > Windows doesn't validate the data when it's passed to ASL and back.
> 
> How do you know?  Who does the "passing"?  The Windows kernel is just a
> blind pipe?  If so, then what does the mappings?

The application or cmdlet calling the method passes the data as described
in the MOF which can be queried from the namespace.

Windows doesn't know anything about what that data is, it can't.  All it knows
is the format of the data as described in the MOF.  It knows which ASL method
to call by the GUID in the MOF which matches the GUID in _WDG which contains
the ASL method.

I can't confidently know which parts of that are done by Windows kernel and
which are handled by Windows userspace.  All I know is that from a "consumer"
of this the application or cmdlet runs in userspace. 

> 
> > It just knows what it looks like, size of the buffer and relays the information.
> 
> relays from/to what?

The ASL method.

Let me try to explain better.
_WDG contains a bunch of objects.
Each of those objects has a GUID, instance count, data type, and two letters that
correspond to an ASL method.
One of those objects is binary MOF.

Binary MOF contains a description of namespaces, objects, their formats etc.
It also contains classes that map to GUIDs.

Windows boots up, some process parses _WDG.
It looks at binary MOF, decompiles/parses it.
It maps the classes to GUIDs, the GUIDs to ASL methods.

You call an object of a class, that will then call the ASL method.

Make more sense?
> 
> > It's up to firmware to block the crazy stuff that you can put in a buffer.
> 
> So userspace can pass any blob it wants to the firmware through this
> interface and the kernel does not parse anything?  How is that
> "protected"?
> 
> > > Again, I like my TPM to work, and I don't want a random rootkit exploit
> > > to be able to destroy it :)
> >
> > I'd like to however point out you can't kill your TPM from this interface.
> 
> On _your_ platform, can you guarantee it on any other platform?  :)
> 
> And I strongly doubt your BIOS would stand up to a good fuzzer, almost
> no firmware can.  Heck, the kernel even has issues, we've been fixing
> them for years...
> 
Well that's software for you.  It will always have problems, but