diff mbox series

x86/64: Add CONFIG_DEVMEM=y for targets/x86/64

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

Commit Message

Supriya Shekhar Mane Feb. 9, 2021, 4:46 p.m. UTC
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(+)

Comments

Tomasz Maciej Nowak Feb. 9, 2021, 5:02 p.m. UTC | #1
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
Alberto Bursi Feb. 9, 2021, 11:13 p.m. UTC | #2
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
Bjørn Mork Feb. 10, 2021, 11:33 a.m. UTC | #3
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
Petr Štetiar Feb. 14, 2021, 8:46 a.m. UTC | #4
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
Petr Štetiar Feb. 14, 2021, 8:47 a.m. UTC | #5
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
Bjørn Mork Feb. 14, 2021, 9:33 a.m. UTC | #6
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
Christian Lamparter Feb. 14, 2021, 10:22 a.m. UTC | #7
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
Petr Štetiar Feb. 14, 2021, 3:08 p.m. UTC | #8
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
Supriya Shekhar Mane March 11, 2021, 3:55 p.m. UTC | #9
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 mbox series

Patch

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