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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <38121adacda24553a7408953157862f4@ausx13mpc120.AMER.DELL.COM>
Date:   Thu, 5 Oct 2017 19:39:05 +0000
From:   <Mario.Limonciello@...l.com>
To:     <pali.rohar@...il.com>, <greg@...ah.com>
CC:     <dvhart@...radead.org>, <andy.shevchenko@...il.com>,
        <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <luto@...nel.org>,
        <quasisec@...gle.com>, <rjw@...ysocki.net>, <mjg59@...gle.com>,
        <hch@....de>
Subject: RE: [PATCH v4 12/14] platform/x86: wmi: create character devices when
 requested by drivers

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@...il.com]
> Sent: Thursday, October 5, 2017 2:33 PM
> To: Greg KH <greg@...ah.com>
> Cc: Limonciello, Mario <Mario_Limonciello@...l.com>; dvhart@...radead.org;
> andy.shevchenko@...il.com; linux-kernel@...r.kernel.org; platform-driver-
> x86@...r.kernel.org; luto@...nel.org; quasisec@...gle.com;
> rjw@...ysocki.net; mjg59@...gle.com; hch@....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@...l.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);