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] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e6691bd-b390-48fe-a132-21db4ac5ff27@suse.com>
Date: Tue, 18 Mar 2025 13:56:54 +0200
From: Nikolay Borisov <nik.borisov@...e.com>
To: Juergen Gross <jgross@...e.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 18.03.25 г. 13:53 ч., Juergen Gross wrote:
> On 18.03.25 12:36, Nikolay Borisov wrote:
>> If a piece of memory is read from /dev/mem that falls outside of the
>> System Ram region i.e bios data region the kernel creates a shared
>> mapping via xlate_dev_mem_ptr() (this behavior was introduced by
>> 9aa6ea69852c ("x86/tdx: Make pages shared in ioremap()"). This results
>> in a region having both a shared and a private mapping.
>>
>> Subsequent accesses to this region via the private mapping induce a
>> SEPT violation and a crash of the VMM. In this particular case the
>> scenario was a userspace process reading something from the bios data
>> area at address 0x497 which creates a shared mapping, and a followup
>> reboot accessing __va(0x472) which access pfn 0 via the private mapping
>> causing mayhem.
>>
>> Fix this by simply forbidding access to /dev/mem when running as an TDX
>> guest.
>>
>> Signed-off-by: Nikolay Borisov <nik.borisov@...e.com>
>> ---
>>
>> Sending this now to hopefully spur up discussion as to how to handle 
>> the described
>> scenario. This was hit on the GCP cloud and was causing their 
>> hypervisor to crash.
>>
>> I guess the most pressing question is what will be the most sensible 
>> approach to
>> eliminate such situations happening in the future:
>>
>> 1. Should we forbid getting a descriptor to /dev/mem (this patch)
>> 2. Skip creating /dev/mem altogether3
>> 3. Possibly tinker with internals of ioremap to ensure that no memory 
>> which is
>> backed by kvm memslots is remapped as shared.
>> 4. Eliminate the access to 0x472 from the x86 reboot path, after all 
>> we don't
>> really have a proper bios at that address.
>> 5. Something else ?
> 
> I think a crash of the VMM must be avoided, otherwise we have a security
> issue due to one TDX guest being able to DoS the complete host.

I agree with this, however this particular crash I haven't been able to 
reproduce locally but was something that came up in the GCP environment. 
So I'd like for someone from google to chime in.

> 
> I'd rather crash the guest for which the SEPT violation was detected (is
> this possible? If not, don't allow it to run any longer maybe?)
 > >
> Juergen