From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753120AbbAQW5A (ORCPT ); Sat, 17 Jan 2015 17:57:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48623 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752039AbbAQW47 (ORCPT ); Sat, 17 Jan 2015 17:56:59 -0500 Message-ID: <54BAE8A0.6070408@redhat.com> Date: Sat, 17 Jan 2015 17:56:32 -0500 From: Jon Masters Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Olof Johansson CC: Catalin Marinas , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: SMBIOS/DMI data under CONFIG_STRICT_DEVMEM References: <54BAC21D.9040009@redhat.com> <54BAE7CB.2010705@redhat.com> In-Reply-To: <54BAE7CB.2010705@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/17/2015 05:52 PM, Jon Masters wrote: > Hi Olof, > > On 01/17/2015 04:10 PM, Olof Johansson wrote: >> Hi, >> >> On Sat, Jan 17, 2015 at 12:12 PM, Jon Masters wrote: >>> Hi Catalin, all, >>> >>> I would like to ensure that the SMBIOS data provided by firmware is >>> always readable from userspace on AArch64, through /dev/mem. >> >> Seems like this would be a good opportunity for cleanup and fixing >> userspace to use /sys/firmware/dmi interfaces instead of having to go >> poking through /dev/mem. That way they don't have to be privileged >> process any more and is a general security benefit for everybody. > > I don't disagree :) > > Indeed, I was pushing within RH years ago to help get it into > /sys/firmware/dmi where it lives today. Someone went over this code for > us a few months ago and the determination was that there's a chunk of > refactoring that needs doing to get it to do the right thing. I think in > the interim some of the vendor kernels might need another solution, but > I've already asked that Linaro refactor the tool to do it right. > > There's probably good reasons to be able to poke at the tables directly > from userspace under certain circumstances too. For example, one of the > reference platforms I am using has bogus checksums in the tables so they > fail to load in the Linux interpreter which means you never see the > entries in /sys/firmware/dmi being created and could not debug why if > you had no direct access to read the raw ones. That means that probably > people would still carry hacks to allow such access. (the reference platform in question above will be corrected shortly)