| Message ID | 20201015164254.7774-1-xypron.glpk@gmx.de |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v2,1/1] lib: enable /dev/mem access on aarch64 | expand |
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>
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 >
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>
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>
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 >>
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
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
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
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
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 --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__)
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