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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 17 Jan 2015 23:21:42 +0000
From:	Leif Lindholm <leif.lindholm@...aro.org>
To:	Jon Masters <jcm@...hat.com>
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 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.

Fortunately, for SMBIOS there is /sys/firmware/dmi. 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.)

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

> 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, but particularly
bad on ARM*, since we don't have anything resembling a predictable
memory map. 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.

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.

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