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] [day] [month] [year] [list]

Date:	Sat, 17 Jan 2015 19:49:30 -0500
From:	Jon Masters <jcm@...hat.com>
To:	Leif Lindholm <leif.lindholm@...aro.org>
CC:	Catalin Marinas <Catalin.Marinas@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

On 01/17/2015 06:21 PM, Leif Lindholm wrote:
> On Sat, Jan 17, 2015 at 03:12:13PM -0500, 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.
> 
> No, we need to ensure /dev/mem can be completely disabled on any
> system that ever wants to have any level of reliability.

I think that's a wonderful goal! And so is world peace. It's even
slightly more achievable than world peace, but in the interim people are
going to want to be able to access memory through /dev/mem. However, in
the short term, if the below patches dmidecode for me, then I'll stop
whining about it and we'll wait for the next person ;)

> Fortunately, for SMBIOS there is /sys/firmware/dmi.

Indeed there is.

> Expect to see some
> patches from Ivan Khoronzhuk on this next week. (He has a working
> prototype of dmidecode, and a couple of minor kernel patches, as of
> yesterday.)

Great! I knew it was coming, I just hadn't heard when.

> For acpidump, there is /sys/firmware/acpi, and we're looking into that
> as well.

That one I'm not so worried about since I just copy the files and run
iasl -d, which I think is what most others do, and very few sysadmin
type tools need to do that directly. But things do call dmidecode.

>> When building a kernel with CONFIG_STRICT_DEVMEM, arm64 follows broadly
>> x86 with the exception of an assumption surrounding the low range of
>> memory (which doesn't apply on AArch64 platforms universally anyway).
>> Thus on x86, they can directly read the SMBIOS table from dmidecode when
>> it tries to map /dev/mem due to its location. I'm hacking something up
>> for the moment, but I would like to solve this.
> 
> STRICT_DEVMEM is a trainwreck on all architectures

Yep. It does seem to be particularly unpleasant.

> but particularly bad on ARM*, since we don't have anything resembling
> a predictable memory map.

In case anyone cares, I did make several formal proposals to standardize
the memory map rigorously on ARM servers precisely for this reason (I
even warned ahead of time about this situation, and that of the runtime
location of EFI, etc.), but hw vendors did not want that. I can but push
to make everything rigidly uniform and boring ;)

> While I like Ard's approach to improve it with data
> actually available, I would also like add the ability to make it
> tweakable as read-write, read-only or no access.

Cool.

> I sent out a series looking to consolidate STRICT_DEVMEM handling
> across architectures (i.e. not have separate definitions per
> architecture Kconfig), but had little response. If anyone is
> interested in seeing that happening, let me know and I'll resend with
> you on cc.

I would love to take a look.

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/