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

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

Dave Hansen wrote:
> On 4/17/25 12:11, Dan Williams wrote:
> >  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(-)
> 
> This looks like a good idea on multiple levels. We can take it through
> tip, but one things that makes me nervous is that neither of the "CHAR
> and MISC DRIVERS" supporters are even on cc.
> 
> > Arnd Bergmann <arnd@arndb.de> (supporter:CHAR and MISC DRIVERS)
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> (supporter:CHAR and MISC DRIVERS)

Good catch, just note that until this latest iteration the proposal was
entirely contained to x86 specific support functions like devmem_is_allowed().
So yes, an oversight as this moved to a more general devmem mechanism.

> I guess arm and powerpc have cc_platform_has() so it's not _completely_
> x86 only, either. Acks from those folks would also be appreciated since
> it's going to affect them most immediately.

I have added Suzuki and Michael for their awareness, but I would not say
acks are needed at this point since to date CC_ATTR_GUEST_MEM_ENCRYPT is
strictly an x86-ism.

For example, the PowerPC implementation of cc_platform_has() has not been
touched since Tom added it. 

Suzuki, Michael, at a minimum the question this patch poses to ARM64 and
PowerPC is whether they are going to allow CONFIG_STRICT_DEVMEM=n, or otherwise
understand that CONFIG_STRICT_DEVMEM=y == LOCKDOWN with
CC_ATTR_GUEST_MEM_ENCRYPT.

> Also, just to confirm, patch 2 can go to stable@ without _any_
> dependency on patch 1, right?

Correct. I will make them independent / unordered patches on the repost.

Next posting to fix the "select" instead of "depends on" dependency
management, h/t Naveen, and clarify the "'crash' vs 'SEPT violation'"
description.