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]

Message-ID: <54BAE8A0.6070408@redhat.com>
Date:	Sat, 17 Jan 2015 17:56:32 -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

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 <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.

(the reference platform in question above will be corrected shortly)


--
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/