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

[Nikolay Borisov <nik.borisov@suse.com>]

On 25.03.25 г. 20:16 ч., Dan Williams wrote:
> 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?


This fixes the issue as now the remapped address and the direct mapping 
are identical.

Tested-by: Nikolay Borisov <nik.borisov@suse.com>

Would you care to send a proper patch ?