Re: [PATCH 3/3] [RFC] x86/devmem: remove low 1MB hack for x86-64

[Dan Williams <dan.j.williams@intel.com>]

[add Kees]

Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Traditionally, both reading and mapping anything in the low 1MB area is
> allowed on x86, through a series of ugly hacks.  In combination with
> features such as memory encryption, this keeps causing trouble and
> requires building additional hacks on top.
> 
> Chances are that this is only really used for 32-bit machines, as the
> usual users of this were dosemu, svgalib or ancient XFree86 versions,
> none of which should be used on 64-bit kernels any more.
> 
> Remove both the custom devmem_is_allowed() and the custom
> xlate_dev_mem_ptr() on 64-bit kernels, and use the normal implementation
> based on phys_to_virt() instead for read/write access on the linear
> map.
> 
> As a result, this makes x86-64 behave more like the other architecture
> on /dev/mem, allowing read/write access only on actual system RAM and
> only when CONFIG_STRICT_DEVMEM is disabled, while mmap() can be use
> on MMIO pages with the normal restrictions.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Unlike the other two patches in this series, this one is expected to
> change the behavior on x86-64 kernels, which has the risk of
> regressions, but seems worthwhile to me.
> 
> Are there any reasons left for keeping these hacks?

Kees did this search which seems to suggest that there is still code out
there that may not be prepared for a behavior change here:

http://lore.kernel.org/202504101926.0F8FB73@keescook

Maybe those paths fallback to dmi sysfs or other mechanisms for digging through
BIOS data, but I do not think we can know for sure that this removal is
regression free ahead of time.

I would be interested to see though, so:

Acked-by: Dan Williams <dan.j.williams@intel.com>