SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

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

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.

SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

[Ard Biesheuvel]

On 17 January 2015 at 20:12, Jon Masters <jcm@redhat.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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

[Jon Masters]

On 01/17/2015 03:59 PM, Ard Biesheuvel wrote:
> On 17 January 2015 at 20:12, Jon Masters <jcm@redhat.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)

Ah. So you have it in hand. Great. We'll go with a temporary workaround
and wait for your series for the fix. Will take a look and review.

Jon.

SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

[Olof Johansson]

Hi,

On Sat, Jan 17, 2015 at 12:12 PM, Jon Masters <jcm@redhat.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.


-Olof

SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

[Jon Masters]

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

Jon.

SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

[Jon Masters]

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@redhat.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)

SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

[Leif Lindholm]

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

SMBIOS/DMI data under CONFIG_STRICT_DEVMEM

[Jon Masters]

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.