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.not... [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.