> -----Original Message-----
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Thursday, November 2, 2017 7:50 PM
> To: Limonciello, Mario <mario_limoncie...@dell.com>
> Cc: Andy Shevchenko <andy.shevche...@gmail.com>; LKML <linux-
> ker...@vger.kernel.org>; platform-driver-...@vger.kernel.org; Andy Lutomirski
> <l...@kernel.org>; quasi...@google.com; pali.ro...@gmail.com;
> r...@rjwysocki.net; mj...@google.com; h...@lst.de; Greg KH <g...@kroah.com>;
> Alan Cox <gno...@lxorguk.ukuu.org.uk>
> Subject: Re: [PATCH v12 00/16] Introduce support for Dell SMBIOS over WMI
> 
> On Wed, Nov 01, 2017 at 02:25:21PM -0500, Mario Limonciello wrote:
> > The existing way that the dell-smbios helper module and associated
> > other drivers (dell-laptop, dell-wmi) communicate with the platform
> > really isn't secure.  It requires creating a buffer in physical
> > DMA32 memory space and passing that to the platform via SMM.
> >
> > Since the platform got a physical memory pointer, you've just got
> > to trust that the platform has only modified (and accessed) memory
> > within that buffer.
> >
> > Dell Platform designers recognize this security risk and offer a
> > safer way to communicate with the platform over ACPI.  This is
> > in turn exposed via a WMI interface to the OS.
> >
> > When communicating over WMI-ACPI the communication doesn't occur
> > with physical memory pointers.  When the ASL is invoked, the fixed
> > length ACPI buffer is copied to a small operating region.  The ASL
> > will invoke the SMI, and SMM will only have access to this operating
> > region.  When the ASL returns the buffer is copied back for the OS
> > to process.
> >
> > This method of communication should also deprecate the usage of the
> > dcdbas kernel module and software dependent upon it's interface.
> > Instead offer a character device interface for communicating with this
> > ASL method to allow userspace to use instead.
> >
> > To faciliate that this patch series introduces a generic way for WMI
> > drivers to be able to create discoverable character devices with
> > a predictable IOCTL interface through the WMI bus when desired.
> > Requiring WMI drivers to explicitly ask for this functionality will
> > act as an effective vendor whitelist to character device creation.
> >
> > Some of this work is the basis for what will be a proper interpreter
> > of MOF in the kernel and controls for what drivers will be able to
> > do with that MOF.
> >
> > NOTE: This patch series is intended to go on top of platform-drivers-x86
> > linux-next.
> >
> > For convenience the entire series including those is also available here:
> > https://github.com/dell/linux/tree/wmi-smbios
> 
> Queued for testing, thanks Mario.
> 
> --
> Darren Hart
> VMware Open Source Technology Center

Thanks Darren.  BTW Did you forget to push?  I didn't see it at the testing 
branch:
http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/shortlog/refs/heads/testing

Thanks,

Reply via email to