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

[Leif Lindholm]

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