From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965262AbdIYQNv (ORCPT ); Mon, 25 Sep 2017 12:13:51 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:33149 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936036AbdIYQNs (ORCPT ); Mon, 25 Sep 2017 12:13:48 -0400 X-Google-Smtp-Source: AOwi7QBnM/3zNsSkciur3olyokIXo0KdBZxR9zC+EnxBnij1wyABLEuu0T1JpcpaRkxZoag2jen46Q== Date: Mon, 25 Sep 2017 18:13:45 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Mario Limonciello 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 Message-ID: <20170925161345.GJ22190@pali> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. Can you describe more details about this security risk? > 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. If problem is in current kernel implementation, then it can be fixed. I'm not against using new WMI communication, but I cannot understand how kernel code itself is less safer as some other code which is interpreted by kernel. It does not make sense for me. > This method of communication should also deprecate the usage of the > dcdbas kernel module and software dependent upon it's interface. > Instead offer a syfs interface for communicating with this ASL > method to allow userspace to use instead. > > To faciliate that needs for userspace and kernel space this patch > series introduces a generic way for WMI drivers to be able to > create character devices through the WMI bus when desired. > Requiring WMI drivers to explictly ask for this functionality will > act as an effective vendor whitelist. -- Pali Rohár pali.rohar@gmail.com