On 11.04.25 г. 4:22 ч., Dan Williams wrote:
Changes since v1 [1]:
- Fix the fact that devmem_is_allowed() == 2 does not prevent mmap access (Kees)
- Rather than teach devmem_is_allowed() == 2 to map zero pages in the mmap case, just fail (Nikolay)
The story starts with Nikolay reporting an SEPT violation due to mismatched encrypted/non-encrypted mappings of the BIOS data space [2].
An initial suggestion to just make sure that the BIOS data space is mapped consistently [3] ran into another issue that TDX and SEV-SNP disagree about when that space can be mapped as encrypted.
Then, in response to a partial patch to allow SEV-SNP to block BIOS data space for other reasons [4], Dave asked why not just give up on /dev/mem access entirely in the confidential VM case [5].
Enter this series to:
1/ Close a subtle hole whereby /dev/mem that is supposed return zeros in lieu of access only enforces that for read()/write()
2/ Use that new closed hole to reliably disable all /dev/mem access for confidential x86 VMs
[5]: http://lore.kernel.org/fd683daa-d953-48ca-8c5d-6f4688ad442c@intel.com
Dan Williams (3): x86/devmem: Remove duplicate range_is_allowed() definition devmem: Block mmap access when read/write access is restricted x86/devmem: Restrict /dev/mem access for potentially unaccepted memory by default
arch/x86/Kconfig | 2 ++ arch/x86/include/asm/x86_init.h | 2 ++ arch/x86/kernel/x86_init.c | 6 ++++++ arch/x86/mm/init.c | 23 +++++++++++++++++------ arch/x86/mm/pat/memtype.c | 31 ++++--------------------------- drivers/char/mem.c | 18 ------------------ include/linux/io.h | 26 ++++++++++++++++++++++++++ 7 files changed, 57 insertions(+), 51 deletions(-)
base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
Reviewed-by: Nikolay Borisov nik.borisov@suse.com