diff mbox series

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

Message ID 20201015164254.7774-1-xypron.glpk@gmx.de
State New
Headers show
Series [v2,1/1] lib: enable /dev/mem access on aarch64 | expand

Commit Message

Heinrich Schuchardt Oct. 15, 2020, 4:42 p.m. UTC
The SMBIOS3 table supplied by U-Boot cannot be read without mmap.

Cc: Leif Lindholm <leif@nuviainc.com>
Fixes: f36ff824d145 ("lib: disable /dev/mem access on aarch64")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
v2:
	Leif's email address has changed
---
 src/lib/include/fwts.h | 1 +
 1 file changed, 1 insertion(+)

--
2.28.0

Comments

Colin Ian King Oct. 15, 2020, 4:48 p.m. UTC | #1
On 15/10/2020 17:42, Heinrich Schuchardt wrote:
> The SMBIOS3 table supplied by U-Boot cannot be read without mmap.
> 
> Cc: Leif Lindholm <leif@nuviainc.com>
> Fixes: f36ff824d145 ("lib: disable /dev/mem access on aarch64")
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
> v2:
> 	Leif's email address has changed
> ---
>  src/lib/include/fwts.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/lib/include/fwts.h b/src/lib/include/fwts.h
> index 6f13d262..a4163055 100644
> --- a/src/lib/include/fwts.h
> +++ b/src/lib/include/fwts.h
> @@ -105,6 +105,7 @@
>  #define FWTS_ARCH_AARCH64	1
>  #define FWTS_HAS_ACPI	1
>  #define FWTS_HAS_UEFI	1
> +#define FWTS_USE_DEVMEM 1
>  #endif
> 
>  #if defined(__s390x__)
> --
> 2.28.0
> 

Unless Lief disagrees, I can't see why not, especially if it allows
testing of the SMBIOS table.

Acked-by: Colin Ian King <colin.king@canonical.com>
Leif Lindholm Oct. 15, 2020, 6:01 p.m. UTC | #2
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.

/
    Leif

> Cc: Leif Lindholm <leif@nuviainc.com>
> Fixes: f36ff824d145 ("lib: disable /dev/mem access on aarch64")
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
> v2:
> 	Leif's email address has changed
> ---
>  src/lib/include/fwts.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/lib/include/fwts.h b/src/lib/include/fwts.h
> index 6f13d262..a4163055 100644
> --- a/src/lib/include/fwts.h
> +++ b/src/lib/include/fwts.h
> @@ -105,6 +105,7 @@
>  #define FWTS_ARCH_AARCH64	1
>  #define FWTS_HAS_ACPI	1
>  #define FWTS_HAS_UEFI	1
> +#define FWTS_USE_DEVMEM 1
>  #endif
> 
>  #if defined(__s390x__)
> --
> 2.28.0
>
Alex Hung Oct. 15, 2020, 6:02 p.m. UTC | #3
On 2020-10-15 10:42 a.m., Heinrich Schuchardt wrote:
> The SMBIOS3 table supplied by U-Boot cannot be read without mmap.
> 
> Cc: Leif Lindholm <leif@nuviainc.com>
> Fixes: f36ff824d145 ("lib: disable /dev/mem access on aarch64")
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
> v2:
> 	Leif's email address has changed
> ---
>  src/lib/include/fwts.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/lib/include/fwts.h b/src/lib/include/fwts.h
> index 6f13d262..a4163055 100644
> --- a/src/lib/include/fwts.h
> +++ b/src/lib/include/fwts.h
> @@ -105,6 +105,7 @@
>  #define FWTS_ARCH_AARCH64	1
>  #define FWTS_HAS_ACPI	1
>  #define FWTS_HAS_UEFI	1
> +#define FWTS_USE_DEVMEM 1
>  #endif
> 
>  #if defined(__s390x__)
> --
> 2.28.0
> 


Acked-by: Alex Hung <alex.hung@canonical.com>
Leif Lindholm Oct. 15, 2020, 6:06 p.m. UTC | #4
On Thu, Oct 15, 2020 at 17:48:45 +0100, Colin Ian King wrote:
> On 15/10/2020 17:42, Heinrich Schuchardt wrote:
> > The SMBIOS3 table supplied by U-Boot cannot be read without mmap.
> > 
> > Cc: Leif Lindholm <leif@nuviainc.com>
> > Fixes: f36ff824d145 ("lib: disable /dev/mem access on aarch64")
> > Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > ---
> > v2:
> > 	Leif's email address has changed
> > ---
> >  src/lib/include/fwts.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/src/lib/include/fwts.h b/src/lib/include/fwts.h
> > index 6f13d262..a4163055 100644
> > --- a/src/lib/include/fwts.h
> > +++ b/src/lib/include/fwts.h
> > @@ -105,6 +105,7 @@
> >  #define FWTS_ARCH_AARCH64	1
> >  #define FWTS_HAS_ACPI	1
> >  #define FWTS_HAS_UEFI	1
> > +#define FWTS_USE_DEVMEM 1
> >  #endif
> > 
> >  #if defined(__s390x__)
> > --
> > 2.28.0
> > 
> 
> Unless Lief disagrees, I can't see why not, especially if it allows
> testing of the SMBIOS table.

Oh, Leif disagrees :)
(See other email.)

On which note, I think you missed an email I sent on this topic for
RISC-V a while back:
https://lists.ubuntu.com/archives/fwts-devel/2020-July/012143.html

Regards,

Leif

> Acked-by: Colin Ian King <colin.king@canonical.com>
Heinrich Schuchardt Oct. 15, 2020, 6:41 p.m. UTC | #5
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.
>
> /
>     Leif

I fully understand your security concerns. But given a kernel that
exposes /dev/mem is there any reason for fwts not to use it?

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.

Best regards

Heinrich

>
>> Cc: Leif Lindholm <leif@nuviainc.com>
>> Fixes: f36ff824d145 ("lib: disable /dev/mem access on aarch64")
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> ---
>> v2:
>> 	Leif's email address has changed
>> ---
>>  src/lib/include/fwts.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/src/lib/include/fwts.h b/src/lib/include/fwts.h
>> index 6f13d262..a4163055 100644
>> --- a/src/lib/include/fwts.h
>> +++ b/src/lib/include/fwts.h
>> @@ -105,6 +105,7 @@
>>  #define FWTS_ARCH_AARCH64	1
>>  #define FWTS_HAS_ACPI	1
>>  #define FWTS_HAS_UEFI	1
>> +#define FWTS_USE_DEVMEM 1
>>  #endif
>>
>>  #if defined(__s390x__)
>> --
>> 2.28.0
>>
Leif Lindholm Oct. 15, 2020, 7:08 p.m. UTC | #6
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
Colin Ian King Oct. 15, 2020, 9:05 p.m. UTC | #7
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
Leif Lindholm Oct. 15, 2020, 9:47 p.m. UTC | #8
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
Colin Ian King Oct. 15, 2020, 9:56 p.m. UTC | #9
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
Heinrich Schuchardt Oct. 15, 2020, 10:28 p.m. UTC | #10
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
diff mbox series

Patch

diff --git a/src/lib/include/fwts.h b/src/lib/include/fwts.h
index 6f13d262..a4163055 100644
--- a/src/lib/include/fwts.h
+++ b/src/lib/include/fwts.h
@@ -105,6 +105,7 @@ 
 #define FWTS_ARCH_AARCH64	1
 #define FWTS_HAS_ACPI	1
 #define FWTS_HAS_UEFI	1
+#define FWTS_USE_DEVMEM 1
 #endif

 #if defined(__s390x__)