lkml.org 
[lkml]   [2017]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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@dell.com 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:
    > https://msdn.microsoft.com/en-us/library/windows/hardware/dn614028(v=vs.85).aspx
    >

    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

    \
     
     \ /
      Last update: 2017-10-05 22:52    [W:3.246 / U:0.684 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site