From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752355AbdI0QkD (ORCPT ); Wed, 27 Sep 2017 12:40:03 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:40007 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752206AbdI0QkB (ORCPT ); Wed, 27 Sep 2017 12:40:01 -0400 Date: Wed, 27 Sep 2017 09:39:58 -0700 From: Darren Hart To: Mario.Limonciello@dell.com Cc: pali.rohar@gmail.com, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, quasisec@google.com Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI Message-ID: <20170927163958.GC23572@fury> References: <20170925161345.GJ22190@pali> <20170925164902.GN22190@pali> <00af0747a69a42c7ad0e9beaf9c50dab@ausx13mpc120.AMER.DELL.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <00af0747a69a42c7ad0e9beaf9c50dab@ausx13mpc120.AMER.DELL.COM> User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 25, 2017 at 07:27:24PM +0000, Mario.Limonciello@dell.com wrote: > > -----Original Message----- > > From: Pali Rohár [mailto:pali.rohar@gmail.com] > > Sent: Monday, September 25, 2017 12:49 PM > > To: Limonciello, Mario > > Cc: dvhart@infradead.org; linux-kernel@vger.kernel.org; platform-driver- > > x86@vger.kernel.org; quasisec@google.com > > Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI > > > > On Monday 25 September 2017 16:32:52 Mario.Limonciello@dell.com wrote: > > > Hi Pali, > > > > > > > -----Original Message----- > > > > From: Pali Rohár [mailto:pali.rohar@gmail.com] > > > > Sent: Monday, September 25, 2017 12:14 PM > > > > To: Limonciello, Mario > > > > Cc: dvhart@infradead.org; LKML ; platform- > > driver- > > > > x86@vger.kernel.org; quasisec@google.com > > > > 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