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

[Colin Ian King]

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

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?

Colin