Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI

[Darren Hart]

On Mon, Sep 25, 2017 at 07:27:24PM +0000, Mario.Limonciello@xxxxxxxx wrote:
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@xxxxxxxxx]
> > Sent: Monday, September 25, 2017 12:49 PM
> > To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> > Cc: dvhart@xxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; platform-driver-
> > x86@xxxxxxxxxxxxxxx; quasisec@xxxxxxxxxx
> > Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> > 
> > On Monday 25 September 2017 16:32:52 Mario.Limonciello@xxxxxxxx wrote:
> > > Hi Pali,
> > >
> > > > -----Original Message-----
> > > > From: Pali Rohár [mailto:pali.rohar@xxxxxxxxx]
> > > > Sent: Monday, September 25, 2017 12:14 PM
> > > > To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> > > > Cc: dvhart@xxxxxxxxxxxxx; LKML <linux-kernel@xxxxxxxxxxxxxxx>; platform-
> > driver-
> > > > x86@xxxxxxxxxxxxxxx; quasisec@xxxxxxxxxx
> > > > Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> > > >
> > > > On Thursday 21 September 2017 08:57:05 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.
> > > >
> > > > And what is the problem? The whole memory management is done by kernel
> > > > itself, so you already need to trust it.
> > >
> > > There's a lot of ifs, but it's not that crazy of a scenario.
> > >
> > > The problem is that if a malicious payload was delivered to the platform
> > > and exercised a vulnerability in the platform code that payload could
> > > potentially modify memory that it wasn't intended to modify and the OS
> > > would not be aware as operating in SMM.
> > >
> > > >
> > > > > 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.
> > > >
> > > > Hm... I cannot understand how some proprietary ACPI bytecode interpreted
> > > > by kernel can be safer as kernel code itself.
> > > >
> > >
> > > Inherently ACPI can only operate on operation regions and not physical memory.
> > > Data passed into ACPI needs to be copied to an operation region for any ACPI
> > > calls to use it.
> > 
> > But operation regions access is implemented by ACPI interpreter, which
> > is again kernel code.
> 
> So isn't that making my point?
> * Kernel can control operation region accessibility.  SMM can't operate outside
> of this region.
> * Direct SMI gives platform access to everything < 4G, kernel can't control this.

I think there may be some confusion with the term "platform code" - it means
different things to different people. I believe Mario is talking about limiting
memory access to the SMI/SMM code through the use of the ACPI op region in place
of the physical memory pointer, which is not visible nor can it be audited.

-- 
Darren Hart
VMware Open Source Technology Center