arm64: defconfig: disable CONFIG_DEVMEM

/dev/mem is the opposite of what an operating system is for. Additionally, on arm* it opens up for denial-of-service attacks from userspace. So leave it disabled by default, requiring people who need it to enable it explicitly.

Signed-off-by Leif Lindholm <[email protected]>

---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

arch/arm64/configs/defconfig +1 -1

index 33b744d..55ba73a 100644
@@ -210,6 +210,7 @@ CONFIG_INPUT_HISI_POWERKEY=y
 # CONFIG_SERIO_SERPORT is not set
 CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
+# CONFIG_DEVMEM is not set
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_EXTENDED=y
--

2.10.2

/dev/mem is the opposite of what an operating system is for. Additionally, on arm* it opens up for denial-of-service attacks from userspace. So leave it disabled by default, requiring people who need it to enable it explicitly.

Signed-off-by Leif Lindholm <[email protected]>

---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

arch/arm64/configs/defconfig +1 -0

index 33b744d..55ba73a 100644
@@ -210,6 +210,7 @@ CONFIG_INPUT_HISI_POWERKEY=y
 # CONFIG_SERIO_SERPORT is not set
 CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
+# CONFIG_DEVMEM is not set
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_EXTENDED=y

Signature · 1 line

2.10.2

/dev/mem is the opposite of what an operating system is for. Additionally, on arm* it opens up for denial-of-service attacks from userspace. So leave it disabled by default, requiring people who need it to enable it explicitly.

Quoted 4 lines · Leif Lindholm

/dev/mem is the opposite of what an operating system is for. Additionally, on arm* it opens up for denial-of-service attacks from userspace. So leave it disabled by default, requiring people who need it to enable it explicitly.

I really like the idea, but are we sure that nothing common breaks without this? For example, does Debian still boot nicely with this patch applied?

Just trying to get a feel for how much userspace this has seen (particularly on ACPI-based systems, which I seem to remember like poking about in here).

On a side note, comparing the resulting configs, there is a semi-broken config dependency in lib/Kconfig.debug, meaning CONFIG_*STRICT_DEVMEM get set even if CONFIG_DEVMEM is not. But I'll send that out as a separate patch.

Quoted 8 lines · Will Deacon

Quoted 4 lines · Leif Lindholm

/dev/mem is the opposite of what an operating system is for. Additionally, on arm* it opens up for denial-of-service attacks from userspace. So leave it disabled by default, requiring people who need it to enable it explicitly.

I really like the idea, but are we sure that nothing common breaks without this? For example, does Debian still boot nicely with this patch applied?

Getting distros to not have to shop around for config fragments in order to be able to a stable system is one of my main purposes of this patch.

Since Debian just published a 4.9 kernel, I gave that a spin (both DT and ACPI). No issues.

Quoted 2 lines

Just trying to get a feel for how much userspace this has seen (particularly on ACPI-based systems, which I seem to remember like poking about in here).

There are various tools that let you figure out various things about the system (a bit like running dtc on a dump of the active device-tree), but nothing actually used for booting a system (much like dtc).

/dev/mem has been used for things like dmidecode and acpidump in the past, but we fixed those tools back in 2015 to use /sys interfaces instead of blindly groping around and hoping for the best.

Stretch version of dmidecode operates as expected on both DT and ACPI boot, and acpidump does in the ACPI case (no tables in /sys otherwise).

There may be other tools that will also break if not implementing support for access via /sys, but none critical for system operation (and currently a denial-of-service waiting to happen anyway).

Systemd will try to access /dev/mem to extract boot timestamp stuff, but handles a failure gracefully (i.e. not even a warning message).

Quoted 10 lines · Leif Lindholm

Quoted 8 lines · Will Deacon

Quoted 4 lines · Leif Lindholm

/dev/mem is the opposite of what an operating system is for. Additionally, on arm* it opens up for denial-of-service attacks from userspace. So leave it disabled by default, requiring people who need it to enable it explicitly.

I really like the idea, but are we sure that nothing common breaks without this? For example, does Debian still boot nicely with this patch applied?

Quoted 6 lines

Getting distros to not have to shop around for config fragments in order to be able to a stable system is one of my main purposes of this patch.

Since Debian just published a 4.9 kernel, I gave that a spin (both DT and ACPI). No issues.

Will, any comments?

Quoted 15 lines · Leif Lindholm

Quoted 14 lines · Leif Lindholm

Quoted 8 lines · Will Deacon

Quoted 4 lines · Leif Lindholm

/dev/mem is the opposite of what an operating system is for. Additionally, on arm* it opens up for denial-of-service attacks from userspace. So leave it disabled by default, requiring people who need it to enable it explicitly.

I really like the idea, but are we sure that nothing common breaks without this? For example, does Debian still boot nicely with this patch applied?

Getting distros to not have to shop around for config fragments in order to be able to a stable system is one of my main purposes of this patch.

Quoted 4 lines

Quoted 2 lines

Since Debian just published a 4.9 kernel, I gave that a spin (both DT and ACPI). No issues.

Will, any comments?

Nope; fine by me. arm-soc usually pick these up.

FWIW, I did do a Debian CodeSearch for /dev/mem and there were more hits than I was hoping for. However, much of the code looked either:

(a) Broken anyway
(b) Not relevant to arm64
(c) /dev/mem was just a string in a comment or something

There are a couple of crazy projects that appear to use /dev/mem to implement a heap, but I really couldn't figure out how that worked.