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

From: Darren Hart
Date: Thu Oct 05 2017 - 16:51:45 EST

On Thu, Oct 05, 2017 at 07:03:24PM +0000, Mario.Limonciello@xxxxxxxx wrote:
> >
> > 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).
> When Windows boots up, _WDG is parsed, the binary MOF is loaded into
> the WMI repository. The MOF describes how named objects map to GUIDs
> which map to ASL.
> >From Powershell or from any application that uses WMI as admin you can
> look up the root namespace and see all objects. You can pass calls back
> and forth. There's all sorts of examples of it here:

A couple snippets from this link which I believe I've shared previously
that clarify the design intent of the WMI mechanism:

ACPI-to-WMI Mapper Goals for Windows Instrumentation:


* Allow OEMs to include OEM-specific data blocks, user-mode-callable
ACPI control methods, and events without requiring any changes to the
ACPI-to-WMI mapper.

* Allow general-purpose data consumer applications--those written
without any special knowledge of the data blocks exposed by a
particular machine--to be able to access and understand the data
blocks, user-mode-callable ACPI control methods, and events being
mapped--including those that are OEM specific.


The following are not goals for the ACPI-to-WMI mapper:

* To have specific knowledge about any data block that passes through
the mapper.

* To provide interfaces specifically for SMBIOS data and functions. The
mapper is an open architecture that is not restricted to SMBIOS data
and functionality.

This model is not consistent with Linux design principles, and Mario's
changes attempt to allow for more kernel oversight by:

* Requiring a driver to be written to bind to any GUID which will expose
WMI methods to userspace. The goal here is to provide an effective
whitelist, and to promote vendor participation (they need to send the
patch, have it reviewed, respond to challenges on the security
implications, etc.)

* In the future, provide for the MOF parsing within the kernel so Linux
will have more ability to audit messaging.

Darren Hart
VMware Open Source Technology Center