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

[Leif Lindholm]

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