[PATCH] arm64: Add translation functions for /dev/mem read/write

On 5 May 2017, at 15:55, Will Deacon [off-list ref] wrote:

quoted

On Thu, May 04, 2017 at 07:40:50AM +0100, Ard Biesheuvel wrote:

quoted

On 3 May 2017 at 22:47, Goel, Sameer [off-list ref] wrote:

quoted

On 5/3/2017 2:18 PM, Leif Lindholm wrote:

quoted

On Wed, May 03, 2017 at 11:07:45AM -0600, Goel, Sameer wrote:

quoted

On 5/3/2017 5:26 AM, Will Deacon wrote:
[adding some /dev/mem fans to cc]

quoted

On Tue, May 02, 2017 at 02:28:05PM -0600, Sameer Goel wrote:
Port architecture specific xlate and unxlate functions for /dev/mem
read/write. This sets up the mapping for a valid physical address if a
kernel direct mapping is not already present.

This is a generic issue as a user space app should not be allowed to crash
the kernel.

quoted

This issue was observed when systemd tried to access performance
pointer record from the FPDT table.

Why is it doing that? Is there not a way to get this via /sys?

There is no ACPI FPDT implementation in the kernel, so the userspace
systemd code is getting the FPDT table contents from /sys
and parsing the entries. The performance pointer record is a
reserved address populated by UEFI and the userspace code tries to
access it using /dev/mem. The physical address is valid, so cannot
push back on the user space code.

OK, so then we need to add support for parsing this table in the
kernel and exposing the referred-to regions in a controllable fashion.
Maybe something that belongs under /sys/firmware/efi (adding Matt), or
maybe something that deserves its own driver.

The only two use-cases for /dev/mem on arm64 are:
- Implementing interfaces in the kernel takes up-front effort.
- Being able to accidentally panic the kernel from userland.

We will see this issue with any access using /dev/mem to a MEMBLOCK_NOMAP marked
memblock. The kernel crash issue has to be fixed irrespective of ACPI FPDT support.

I reported the same issue a couple of weeks ago [0]. So while we all
agree that such accesses shouldn't oops the kernel, I think we may
disagree on whether such accesses should be allowed in the first
place, especially when using read/write on /dev/mem (as opposed to
mmap())

Did you plan to respin those patches to address Alex's comments? I agree
that it would be good to close the oops, regardless of the rest of the
discussion here.

Agreed. I will look into this after my vacation (back on May 15th)