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

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

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?