Message ID | 20210209164637.129459-1-sm.supriya@globaledgesoft.com |
---|---|
State | Changes Requested |
Delegated to: | Petr Štetiar |
Headers | show |
Series | x86/64: Add CONFIG_DEVMEM=y for targets/x86/64 | expand |
Hi. W dniu 09.02.2021 o 17:46, Supriya Mane pisze: > Setting 'CONFIG_DEVMEM=y' provides access to /dev/mem. > Fixes "cannot access '/dev/mem' : No such file or directory" > > Signed-off-by: Supriya Mane <sm.supriya@globaledgesoft.com> > --- > target/linux/x86/64/config-5.4 | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/linux/x86/64/config-5.4 b/target/linux/x86/64/config-5.4 > index f09deca5b0..a483d6ea2a 100644 > --- a/target/linux/x86/64/config-5.4 > +++ b/target/linux/x86/64/config-5.4 > @@ -115,6 +115,7 @@ CONFIG_CRYPTO_SIMD=y > # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set > CONFIG_CRYPTO_XTS=y > # CONFIG_DEBUG_HOTPLUG_CPU0 is not set > +CONFIG_DEVMEM=y > CONFIG_DMA_ACPI=y > CONFIG_DMA_SHARED_BUFFER=y > # CONFIG_DPTF_POWER is not set > Normally for Your own compiled images You set it in: Global build settings > Kernel build options > /dev/mem virtual device support Why do You need it enabled by default for OpenWrt provided images at https://openwrt.org/downloads? Regards
On 09/02/21 17:46, Supriya Mane wrote: > Setting 'CONFIG_DEVMEM=y' provides access to /dev/mem. > Fixes "cannot access '/dev/mem' : No such file or directory" > > Signed-off-by: Supriya Mane <sm.supriya@globaledgesoft.com> > --- > target/linux/x86/64/config-5.4 | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/linux/x86/64/config-5.4 b/target/linux/x86/64/config-5.4 > index f09deca5b0..a483d6ea2a 100644 > --- a/target/linux/x86/64/config-5.4 > +++ b/target/linux/x86/64/config-5.4 > @@ -115,6 +115,7 @@ CONFIG_CRYPTO_SIMD=y > # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set > CONFIG_CRYPTO_XTS=y > # CONFIG_DEBUG_HOTPLUG_CPU0 is not set > +CONFIG_DEVMEM=y > CONFIG_DMA_ACPI=y > CONFIG_DMA_SHARED_BUFFER=y > # CONFIG_DPTF_POWER is not set > It's disabled by default because it is a debugging feature that is not terribly secure (lets anyone see the RAM contents, to an extent). I'm not sure this should be enabled for all x86_64 target like that. -Alberto
Alberto Bursi <bobafetthotmail@gmail.com> writes: > On 09/02/21 17:46, Supriya Mane wrote: >> Setting 'CONFIG_DEVMEM=y' provides access to /dev/mem. >> Fixes "cannot access '/dev/mem' : No such file or directory" >> Signed-off-by: Supriya Mane <sm.supriya@globaledgesoft.com> >> --- >> target/linux/x86/64/config-5.4 | 1 + >> 1 file changed, 1 insertion(+) >> diff --git a/target/linux/x86/64/config-5.4 >> b/target/linux/x86/64/config-5.4 >> index f09deca5b0..a483d6ea2a 100644 >> --- a/target/linux/x86/64/config-5.4 >> +++ b/target/linux/x86/64/config-5.4 >> @@ -115,6 +115,7 @@ CONFIG_CRYPTO_SIMD=y >> # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set >> CONFIG_CRYPTO_XTS=y >> # CONFIG_DEBUG_HOTPLUG_CPU0 is not set >> +CONFIG_DEVMEM=y >> CONFIG_DMA_ACPI=y >> CONFIG_DMA_SHARED_BUFFER=y >> # CONFIG_DPTF_POWER is not set >> > > It's disabled by default because it is a debugging feature that is not > terribly secure (lets anyone see the RAM contents, to an extent). > > I'm not sure this should be enabled for all x86_64 target like that. Sure you aren't thinking about DEVKMEM now? DEVMEM is a standard feature, defaulting to Y in the kernel config: config DEVMEM bool "/dev/mem virtual device support" default y help Say Y here if you want to support the /dev/mem device. The /dev/mem device is used to access areas of physical memory. When in doubt, say "Y". and it's enabled in other distro kernels, like Debian (stable and unstable) and RHEL (7 and 8). Bjørn
Bjørn Mork <bjorn@mork.no> [2021-02-10 12:33:44]: Hi, > DEVMEM is a standard feature, defaulting to Y in the kernel config: but it does not mean, that it's something you would like to have enabled by default. > and it's enabled in other distro kernels, like Debian (stable and > unstable) and RHEL (7 and 8). I assume it's for some legacy reasons which don't apply in 2021 to OpenWrt. -- ynezz
Tomasz Maciej Nowak <tmn505@gmail.com> [2021-02-09 18:02:13]: Hi, > Why do You need it enabled by default for OpenWrt provided images at > https://openwrt.org/downloads? answer to this question should be addressed in v2 of this patch. FYI it's very unlikely, that we would enable this feature in default images. Cheers, Petr
Petr Štetiar <ynezz@true.cz> writes:
> I assume it's for some legacy reasons which don't apply in 2021 to OpenWrt.
Not sure I understand what you mean here. There was a a request for
this feature, so it obviously applies to OpenWrt. And it's already
enabled for the ipq807x and rockchip targets, so you can't really claim
that it's not available in OpenWrt either.
I do hope you don't think OpenWrt is somehow more secure than a current
Debian installation because you arbitrarily remove kernel features like
this one?
/dev/mem doesn't change anything security-wise. The security issues in
OpenWrt are caused by almost every process running as root. This is why
every process has access to the hardware. It has nothing to do with the
availability of kernel interfaces. A rogue application can just load
the kernel code it needs anyway.
Bjørn
On 14/02/2021 10:33, Bjørn Mork wrote: > Petr Štetiar <ynezz@true.cz> writes: > >> I assume it's for some legacy reasons which don't apply in 2021 to OpenWrt. > > Not sure I understand what you mean here. There was a a request for > this feature, so it obviously applies to OpenWrt. And it's already > enabled for the ipq807x and rockchip targets, so you can't really claim > that it's not available in OpenWrt either. Hmm, I think I was bitten by this before... In my case setting a CONFIG_DEVMEM=y in any of the targets-config like this did not what its supposed to do. This was because this setting gets "forced" by the CONFIG KERNEL_DEVMEM in our own config/Config-kernel.in. So we might as well remove the CONFIG_DEVMEM from all subtarget configuration. (I think the target/generic/config-X can stay or there will be edit-wars). (My best guess how these settings end up in the targets config, is that these settings get there by accident when the configurations are refreshed upon a kernel-bump.) Cheers, Christian
Bjørn Mork <bjorn@mork.no> [2021-02-14 10:33:15]: Hi, > And it's already enabled for the ipq807x and rockchip targets, so you can't > really claim that it's not available in OpenWrt either. thanks to bringing this to my attention, but I tend to believe, that this is not intentional. > I do hope you don't think OpenWrt is somehow more secure than a current > Debian installation because you arbitrarily remove kernel features like > this one? Unless there is a good reason to have this enabled, it should stay disabled in official builds and "but Debian has it enabled" is not valid argument either. > The security issues in OpenWrt are caused by almost every process running as > root. Thanks to Daniel, this is getting reduced like dnsmasq, logd, ntp, ubus to name a few. Cheers, Petr
Petr Štetiar <ynezz@true.cz> writes: Dear Maintainers, > Unless there is a good reason to have this enabled, it should stay > disabled in official builds and "but Debian has it enabled" is not > valid argument either. Now that it's being decided that macro CONFIG_DEVMEM shall not be enabled by default, why can't bug ID FS#3461 be closed? Regards, Supriya Mane On Thu, Mar 11, 2021 at 6:24 PM Supriya Shekhar Mane <sm.supriya@globaledgesoft.com> wrote: > > Hi Petr, > > As CONFIG_DEVMEM shall not be enabled by default, then this ticket can be moved to closure. > Please suggest the closing procedure. > > Regards, > Supriya Mane > > On Sun, Feb 14, 2021 at 8:39 PM Petr Štetiar <ynezz@true.cz> wrote: >> >> Bjørn Mork <bjorn@mork.no> [2021-02-14 10:33:15]: >> >> Hi, >> >> > And it's already enabled for the ipq807x and rockchip targets, so you can't >> > really claim that it's not available in OpenWrt either. >> >> thanks to bringing this to my attention, but I tend to believe, that this is >> not intentional. >> >> > I do hope you don't think OpenWrt is somehow more secure than a current >> > Debian installation because you arbitrarily remove kernel features like >> > this one? >> >> Unless there is a good reason to have this enabled, it should stay disabled in >> official builds and "but Debian has it enabled" is not valid argument either. >> >> > The security issues in OpenWrt are caused by almost every process running as >> > root. >> >> Thanks to Daniel, this is getting reduced like dnsmasq, logd, ntp, ubus to >> name a few. >> >> Cheers, >> >> Petr >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
diff --git a/target/linux/x86/64/config-5.4 b/target/linux/x86/64/config-5.4 index f09deca5b0..a483d6ea2a 100644 --- a/target/linux/x86/64/config-5.4 +++ b/target/linux/x86/64/config-5.4 @@ -115,6 +115,7 @@ CONFIG_CRYPTO_SIMD=y # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set CONFIG_CRYPTO_XTS=y # CONFIG_DEBUG_HOTPLUG_CPU0 is not set +CONFIG_DEVMEM=y CONFIG_DMA_ACPI=y CONFIG_DMA_SHARED_BUFFER=y # CONFIG_DPTF_POWER is not set
Setting 'CONFIG_DEVMEM=y' provides access to /dev/mem. Fixes "cannot access '/dev/mem' : No such file or directory" Signed-off-by: Supriya Mane <sm.supriya@globaledgesoft.com> --- target/linux/x86/64/config-5.4 | 1 + 1 file changed, 1 insertion(+)