lkml.org 
[lkml]   [2017]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v4 12/14] platform/x86: wmi: create character devices when requested by drivers
Date
> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Thursday, October 5, 2017 2:33 PM
> To: Greg KH <greg@kroah.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> andy.shevchenko@gmail.com; linux-kernel@vger.kernel.org; platform-driver-
> x86@vger.kernel.org; luto@kernel.org; quasisec@google.com;
> rjw@rjwysocki.net; mjg59@google.com; hch@lst.de
> Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when
> requested by drivers
>
> Hi Greg! I would answer some of your question...
>
> On Thursday 05 October 2017 21:09:48 Greg KH wrote:
> > On Thu, Oct 05, 2017 at 07:03:24PM +0000, Mario.Limonciello@dell.com wrote:
> > > 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"?
>
> I described it in my email. Binary MOF is in ACPI buffer returned by
> well known ACPI function.
>
> Vendor fills into DSDT ACPI table (part of BIOS firmware) at correct
> place binary MOF buffer and ACPI interpreter which is part of kernel can
> access it.
>
> > > When Windows boots up, _WDG is parsed,
> >
> > Who parses it, the Windows kernel?
>
> Yes, some Windows kernel driver parses ACPI's _WDG and also binary MOF
> buffer from ACPI.
>
> > > the binary MOF is loaded into the WMI repository.
> >
> > Who does the loading? Where does the "WMI repository" live?
>
> IIRC it can be loaded by both userspace and kernel. No idea about
> permissions, but ACPI/WMI kernel driver loads that binary MOF from ACPI
> table.
>
> Via some tools user can loads also its own MOF buffer into "WMI
> repository".
>
> > > 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"?
>
> In that binary MOF is described C++ style object system and mapping from
> those class/objects into ACPI methods. With information how are mapped
> object method parameters (e.g. integer, strings, structures...) into
> ACPI buffer. And in Windows you can IIRC call those class/objects
> defined in MOF and something (I bet Windows kernel driver) translate
> class method parameters (integers, strings, ...) into kernel ACPI
> buffers and call correct ACPI method. So there is just protection that
> method is called with correct "signature".
>
> But IIRC Dell describe in its MOF object system, that there is one class
> with just one method which has parameter "String" at specified size --
> which maps 1:1 to ACPI buffer.
>

In the current MOF implementation for Dell SMBIOS calling interface yes similar
to your description.
One class describes data filled with bytes, and then the class for making the
call will use that as an argument.

class BDat {
[WmiDataId(1), read, write, Description("data")] uint8 Bytes[WMI_PACKAGE_SIZE]; };

void DoBFn([in, out, Description("Fn buf")] BDat Data);

\
 
 \ /
  Last update: 2017-10-05 21:39    [W:0.316 / U:0.604 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site