Changes since v3 [1] (note v4 was a partial re-roll, but more feedback came in requiring a v5): - Fix a kbuild robot report for a missing header include of cc_platform.h - Switch to selecting STRICT_DEVMEM and IOSTRICT_DEVMEM rather than "depends on". (Naveen) - Clarify the "SEPT violation" vs "crash" and other changelog fixups for devmem maintainers and other arch maintainers. (Dave) - Drop patch numbering since patch2 is a fix and has no dependencies on patch1
[1]: http://lore.kernel.org/174491711228.1395340.3647010925173796093.stgit@dwilli...
--- The original response to Nikolay's report of a "crash" (unhandled SEPT violation) triggered by /dev/mem access to private memory was "let's just turn off /dev/mem".
After some machinations of x86_platform_ops to block a subset of problematic access, spelunking the history of devmem_is_allowed() returning "2" to enable some compatibility benefits while blocking access, and discovering that userspace depends buggy kernel behavior for mmap(2) of the first 1MB of memory on x86, the proposal has circled back to "disable /dev/mem".
Require both STRICT_DEVMEM and IO_STRICT_DEVMEM for x86 confidential guests to close /dev/mem hole while still allowing for userspace mapping of PCI MMIO as long as the kernel and userspace are not mapping the range at the same time.
The range_is_allowed() cleanup is not strictly necessary, but might as well close a 17 year-old "TODO".
Dan Williams (2): x86/devmem: Remove duplicate range_is_allowed() definition x86/devmem: Drop /dev/mem access for confidential guests
arch/x86/Kconfig | 4 ++++ arch/x86/mm/pat/memtype.c | 31 ++++--------------------------- drivers/char/mem.c | 28 ++++++++++------------------ include/linux/io.h | 21 +++++++++++++++++++++ 4 files changed, 39 insertions(+), 45 deletions(-)
base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8