[fwts PATCH v2 1/1] lib: enable /dev/mem access on aarch64

[Colin Ian King]

On 15/10/2020 22:47, Leif Lindholm wrote:
> On Thu, Oct 15, 2020 at 22:05:31 +0100, Colin Ian King wrote:
>> On 15/10/2020 20:08, Leif Lindholm wrote:
>>> On Thu, Oct 15, 2020 at 20:41:57 +0200, Heinrich Schuchardt wrote:
>>>> On 15.10.20 20:01, Leif Lindholm wrote:
>>>>> On Thu, Oct 15, 2020 at 18:42:54 +0200, Heinrich Schuchardt wrote:
>>>>>> The SMBIOS3 table supplied by U-Boot cannot be read without mmap.
>>>>>
>>>>> In order to access SMBIOS on anything other than pre-UEFI x86 systems,
>>>>> linux should be built with CONFIG_DMI_SYSFS
>>>>>
>>>>> /dev/mem is the opposite of what operating systems are for, and
>>>>> enabling it on any ARM system leads to trivial (and frequently
>>>>> accidental) denial-of-service attacks from userland.
>>>>
>>>> I fully understand your security concerns. But given a kernel that
>>>> exposes /dev/mem is there any reason for fwts not to use it?
>>>
>>> If I need to hammer a nail in, is there any reason I shouldn't use
>>> this bottle of nitroglycerine in front of me if the hammer is out in
>>> the shed?
>>>
>>> When we started getting arm systems having more interactive use
>>> (thanks to cheap development boards becoming available), and arm64
>>> was being bootstrapped by distros, we started getting hilarious bug
>>> reports like "I ran dmidecode/lshw and my machine deadlocked".
>>> There are all kinds of unsafe utilities written for PC systems that
>>> will blindly go scanning around what is always DRAM in a PC for
>>> various signatured.
>>>
>>> Last time I tried to get /dev/mem disabled by default upstream (or
>>> banned completely on arm/arm64) there was pushback "beacuse there are
>>> users". Keeping code that "uses /dev/mem if it exists" makes this
>>> argument harder.
>>>
>>> If that isn't enough to convince you, have a look at the commit
>>> message for d8139c72267c.
>>>
>>>> I based my v5.9 kernel on arm64 defconfig. The defconfig has
>>>> CONFIG_DMI_SYSFS=n, CONFIG_DEVMEM=y. The Debian v5.8 kernel has
>>>> CONFIG_DMI_SYSFS=y, CONFIG_DEVMEM=y.
>>>
>>> Yes, I should probably go back and try to get /dev/mem disabled
>>> completely for arm64.
>>
>> Yep, x86 set a bad precedent for this.  I'm not so familiar with non-x86
>> systems, so is there an alternative way to get SMBIOS info w/o using
>> /dev/mem?
> 
> Yes. Everything works fine if the kernel is built with
> CONFIG_DMI_SYSFS, which exposes the SMBIOS data as files under
> /sys/firmware/dmi. That functionality was what enabled us to get rid
> of /dev/mem for arm/aarch64 in fwts in the first place, and why the
> patch of mine that was tagged as "Fixes: " in this submission was
> submitted in the first place.
> 
> /
>     Leif
> 
Thanks for the reminder, I completely forgot that detail. Doh.

Colin