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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <68002191c4733_71fe294da@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 16 Apr 2025 14:30:57 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Naveen N Rao <naveen@...nel.org>, Dan Williams <dan.j.williams@...el.com>
CC: <dave.hansen@...ux.intel.com>, <x86@...nel.org>, Ingo Molnar
	<mingo@...nel.org>, Vishal Annapurve <vannapurve@...gle.com>, Kirill Shutemov
	<kirill.shutemov@...ux.intel.com>, Nikolay Borisov <nik.borisov@...e.com>,
	<stable@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] x86/devmem: Restrict /dev/mem access for
 potentially unaccepted memory by default

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.