Re: [PATCH v2 3/3] x86/devmem: Restrict /dev/mem access for potentially unaccepted memory by default

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

Naveen N Rao wrote:
> On Thu, Apr 10, 2025 at 06:22:38PM -0700, Dan Williams wrote:
> > Nikolay reports [1] that accessing BIOS data (first 1MB of the physical
> > address space) via /dev/mem results in an SEPT violation.
> > 
> > The cause is ioremap() (via xlate_dev_mem_ptr()) establishes an
> > unencrypted mapping where the kernel had established an encrypted
> > mapping previously.
> > 
> > An initial attempt to fix this revealed that TDX and SEV-SNP have
> > different expectations about which and when address ranges can be mapped
> > via /dev/mem.
> > 
> > Rather than develop a precise set of allowed /dev/mem capable TVM
> > address ranges, teach devmem_is_allowed() to always restrict access to
> > the BIOS data space.
> 
> This patch does more than just restrict the BIOS data space - it rejects 
> all accesses to /dev/mem _apart_ from the first 1MB. That should be made 
> clear here.
> 

Agree, and per the follow on conversation [1] even that low 1MB access to
return zeroes is not helpful. Confidential Computing userspace should
drop its dependency on interfaces that are difficult to make compatible
with consistent encryption policy and acceptance status.

http://lore.kernel.org/67f98e27a799e_7205294e3@dwillia2-xfh.jf.intel.com.notmuch [1]

[..]
> >  int devmem_is_allowed(unsigned long pagenr)
> >  {
> > +	bool platform_allowed = x86_platform.devmem_is_allowed(pagenr);
> > +
> 
> If we are going to do this, I don't see the point of having an 
> x86_platform_op. It may be better to simply gate this on  
> cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) directly here.

That is fair, no point in premature flexibility.