SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

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.

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.

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 at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 5 lines · Jon Masters

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

Quoted 7 lines

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)

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.

Hi,

Quoted 2 lines · Jon Masters

Hi Catalin, all,

Quoted 2 lines

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.

Hi Olof,

Quoted 5 lines · Olof Johansson

Hi,

Quoted 2 lines · Jon Masters

Hi Catalin, all,

Quoted 7 lines

Quoted 2 lines

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.

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.

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.

Quoted 4 lines · Jon Masters

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.

Quoted 6 lines

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.