linux-kernel - Re: SMBIOS/DMI data under CONFIG_STRICT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 17 Jan 2015 17:52:59 -0500
From:	Jon Masters <jcm@...hat.com>
To:	Olof Johansson <olof@...om.net>
CC:	Catalin Marinas <Catalin.Marinas@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

Hi Olof,

On 01/17/2015 04:10 PM, Olof Johansson wrote:
> Hi,
> 
> On Sat, Jan 17, 2015 at 12:12 PM, Jon Masters <jcm@...hat.com> 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.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/