RE: [PATCH v12 00/16] Introduce support for Dell SMBIOS over WMI
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, November 3, 2017 4:01 PM > To: Limonciello, Mario <mario_limoncie...@dell.com> > Cc: andy.shevche...@gmail.com; linux-kernel@vger.kernel.org; platform-driver- > x...@vger.kernel.org; l...@kernel.org; quasi...@google.com; > pali.ro...@gmail.com; r...@rjwysocki.net; mj...@google.com; h...@lst.de; > g...@kroah.com; gno...@lxorguk.ukuu.org.uk > Subject: Re: [PATCH v12 00/16] Introduce support for Dell SMBIOS over WMI > > On Fri, Nov 03, 2017 at 04:30:13PM +, mario.limoncie...@dell.com wrote: > > > -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 > > 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, > > > > The workflow currently goes first to review-dvhart, which 0-day will pull > from, > then to testing for integration, then to for-next. I plan to move it to > testing > today. Gotcha, thanks.
RE: [PATCH v12 00/16] Introduce support for Dell SMBIOS over WMI
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, November 3, 2017 4:01 PM > To: Limonciello, Mario > Cc: andy.shevche...@gmail.com; linux-kernel@vger.kernel.org; platform-driver- > x...@vger.kernel.org; l...@kernel.org; quasi...@google.com; > pali.ro...@gmail.com; r...@rjwysocki.net; mj...@google.com; h...@lst.de; > g...@kroah.com; gno...@lxorguk.ukuu.org.uk > Subject: Re: [PATCH v12 00/16] Introduce support for Dell SMBIOS over WMI > > On Fri, Nov 03, 2017 at 04:30:13PM +, mario.limoncie...@dell.com wrote: > > > -Original Message- > > > From: Darren Hart [mailto:dvh...@infradead.org] > > > Sent: Thursday, November 2, 2017 7:50 PM > > > To: Limonciello, Mario > > > Cc: Andy Shevchenko ; LKML > > ker...@vger.kernel.org>; platform-driver-...@vger.kernel.org; Andy > Lutomirski > > > ; quasi...@google.com; pali.ro...@gmail.com; > > > r...@rjwysocki.net; mj...@google.com; h...@lst.de; Greg KH > ; > > > Alan Cox > > > 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, > > > > The workflow currently goes first to review-dvhart, which 0-day will pull > from, > then to testing for integration, then to for-next. I plan to move it to > testing > today. Gotcha, thanks.
Re: [PATCH v12 00/16] Introduce support for Dell SMBIOS over WMI
On Fri, Nov 03, 2017 at 04:30:13PM +, mario.limoncie...@dell.com wrote: > > -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 > 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, > The workflow currently goes first to review-dvhart, which 0-day will pull from, then to testing for integration, then to for-next. I plan to move it to testing today. -- Darren Hart VMware Open Source Technology Center
Re: [PATCH v12 00/16] Introduce support for Dell SMBIOS over WMI
On Fri, Nov 03, 2017 at 04:30:13PM +, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Darren Hart [mailto:dvh...@infradead.org] > > Sent: Thursday, November 2, 2017 7:50 PM > > To: Limonciello, Mario > > Cc: Andy Shevchenko ; LKML > ker...@vger.kernel.org>; platform-driver-...@vger.kernel.org; Andy > > Lutomirski > > ; quasi...@google.com; pali.ro...@gmail.com; > > r...@rjwysocki.net; mj...@google.com; h...@lst.de; Greg KH ; > > Alan Cox > > 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, > The workflow currently goes first to review-dvhart, which 0-day will pull from, then to testing for integration, then to for-next. I plan to move it to testing today. -- Darren Hart VMware Open Source Technology Center
RE: [PATCH v12 00/16] Introduce support for Dell SMBIOS over WMI
> -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 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,
RE: [PATCH v12 00/16] Introduce support for Dell SMBIOS over WMI
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Thursday, November 2, 2017 7:50 PM > To: Limonciello, Mario > Cc: Andy Shevchenko ; LKML ker...@vger.kernel.org>; platform-driver-...@vger.kernel.org; Andy Lutomirski > ; quasi...@google.com; pali.ro...@gmail.com; > r...@rjwysocki.net; mj...@google.com; h...@lst.de; Greg KH ; > Alan Cox > 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,
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
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
