Re: [RFC PATCH] /dev/mem: Disable /dev/mem under TDX guest
From: Dan Williams
Date: Tue Mar 25 2025 - 14:17:25 EST
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?