Re: [PATCH v3 0/2] Restrict devmem for confidential VMs

[Nikolay Borisov <nik.borisov@suse.com>]

On 17.04.25 г. 22:11 ч., Dan Williams wrote:
> Changes since v2 [1]:
> * Drop the new x86_platform_op and just use
>    cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) directly where needed
>    (Naveen)
> * Make the restriction identical to lockdown and stop playing games with
>    devmem_is_allowed()
> * Ensure that CONFIG_IO_STRICT_DEVMEM is enabled to avoid conflicting
>    mappings for userspace mappings of PCI MMIO.
> 
> The original response to Nikolay's report of an 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        |   27 +++++++++------------------
>   include/linux/io.h        |   21 +++++++++++++++++++++
>   4 files changed, 38 insertions(+), 45 deletions(-)
> 
> base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8


Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>