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

Open Source and information security mailing list archives

Message-ID: <CAKv+Gu_kZ+b8CBbiWLW3KW5Nw7qewpN7+N6a910dFaiRcs1xKQ@mail.gmail.com>
Date:	Sat, 17 Jan 2015 20:59:02 +0000
From:	Ard Biesheuvel <ard.biesheuvel@...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 17 January 2015 at 20:12, 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.
>

This has been on our radar for a while

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

Check out my series here
http://article.gmane.org/gmane.linux.kernel.efi/5133

The general idea is to remove all UEFI runtime regions (including
config tables) from the linear mapping, and allow r/o access via
/dev/mem to such regions, using a mapping type which can support
unaligned access (which is required for SMBIOS). As for the iomem
resources, we need to reserve the regions we know are in use,
regardless of how that affects the existing logic around
devmem_is_allowed (and I am sure we can do better than what
page_is_ram currently does, which is matching the string 'System RAM'
against the iomem resource table)

-- 
Ard.

> Here are two questions:
>
> 1). Would you prefer to add e.g. a devmem_is_firmware_table() function
> that is called by devmem_is_allowed and carves out a couple exceptions
> based upon knowing .e.g dmi_base and other dynamic data during boot?
>
> 2). Would you prefer to reserve the DMI region is an iomem resource?
> That's a hack but it would seem to work since your check should then
> result in the kernel's resource management saying this is not RAM. The
> problem with this option is that you would then only be able to read the
> SMBIOS tables from userspace if the kernel also recognized them (i.e.
> option 1 above just checks the reported range from EFI, but this option
> would rely on the kernel DMI code also validating the tables, so if you
> were debugging or whatever you wouldn't be able to read them without
> building your kernel without CONFIG_STRICT_DEVMEM for e.g.).
>
> I'm also curious whether x86 is interested in changing the way that the
> SMBIOS tables are accounted or if there are other suggestions.
>
> Jon.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/

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