linux-kernel - Re: [RFC PATCH] /dev/mem: Disable /dev/mem under TDX guest

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 for Android: free password hash cracker in your pocket

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

Message-ID: <67e2f315af42e_50a3294d4@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Date: Tue, 25 Mar 2025 14:16:53 -0400
From: Dan Williams <dan.j.williams@...el.com>
To: Nikolay Borisov <nik.borisov@...e.com>, Dan Williams
	<dan.j.williams@...el.com>, <dave.hansen@...ux.intel.com>
CC: <kirill.shutemov@...ux.intel.com>, <linux-coco@...ts.linux.dev>,
	<x86@...nel.org>, <linux-kernel@...r.kernel.org>, <vannapurve@...gle.com>
Subject: Re: [RFC PATCH] /dev/mem: Disable /dev/mem under TDX guest

Nikolay Borisov wrote:
[..]
> > It seems unfortunate that the kernel is allowing conflicting mappings of
> > the same pfn. Is this not just a track_pfn_remap() bug report? In other
> > words, whatever established the conflicting private mapping failed to do
> > a memtype_reserve() with the encryption setting such that
> > track_pfn_remap() could find it and enforce a consistent mapping.
> 
> I'm not an expert into this, but looking at the code it seems 
> memtype_reserve deals with the memory type w.r.t PAT/MTRR i.e the 
> cacheability of the memory, not whether the mapping is consistent w.r.t 
> to other, arbitrary attributes.

Right, but the observation is that "something" decides to map that first
page of memory as private and then xlate_dev_mem_ptr() fails to maintain
consistent mapping.

So memtype_reserve() is indeed an awkward place to carry this
information and overkill for this particular bug.

However, something like the following is more appropriate than saying
/dev/mem is outright forbidden for guests.

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 38ff7791a9c7..4a7a5fc83039 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -122,6 +122,10 @@ static void __ioremap_check_other(resource_size_t addr, struct ioremap_desc *des
                return;
        }
 
+       /* Ensure BIOS data (see devmem_is_allowed()) is consistently mapped */
+       if (PHYS_PFN(addr) < 256)
+               desc->flags |= IORES_MAP_ENCRYPTED;
+
        if (!IS_ENABLED(CONFIG_EFI))
                return;
 
...because if the guest image wants to trust root why enforce piecemeal
lockdown semantics?