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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <90b3e063-9587-40a9-90e6-1ad792c4a175@suse.com>
Date: Fri, 28 Mar 2025 12:51:40 +0200
From: Nikolay Borisov <nik.borisov@...e.com>
To: 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



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@...e.com>

Would you care to send a proper patch ?