[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fwts-devel
Subject:    Re: [fwts PATCH v2 1/1] lib: enable /dev/mem access on aarch64
From:       Heinrich Schuchardt <xypron.glpk () gmx ! de>
Date:       2020-10-15 22:28:39
Message-ID: 4150891f-ff6a-7189-2c39-5e13e40de978 () gmx ! de
[Download RAW message or body]

On 10/15/20 11:56 PM, Colin Ian King wrote:
> 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.

What I am missing in the fwts documentation is a list of Kconfig options
that need to be enabled in the kernel to run fwts.

These are the ones I stumbled upon:

CONFIG_EFI_TEST=m
CONFIG_CGROUP_FREEZER=y
CONFIG_DMI_SYSFS=y
# Disable lockdown
CONFIG_LSM=yama,loadpin,safesetid,integrity,bpf
# for snap support:
CONFIG_SQUASHFS_XZ=y

Maybe disabling lockdown is only necessary if CONFIG_DMI_SYSFS=n. This
needs to be checked.

Best regards

Heinrich

-- 
fwts-devel mailing list
fwts-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/fwts-devel

[prev in list] [next in list] [prev in thread] [next in thread]