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: <24826c2b-f1d2-408a-b8d1-63e1882b0fd0@suse.com>
Date: Tue, 18 Mar 2025 12:53:16 +0100
From: Juergen Gross <jgross@...e.com>
To: Nikolay Borisov <nik.borisov@...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 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'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

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)