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: <guatjzjzipzjzvj4oou2gktxmzileawshxmxj22hsa5kmet5g4@2rhf7tzaiytw>
Date: Tue, 18 Mar 2025 14:23:11 +0200
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Nikolay Borisov <nik.borisov@...e.com>
Cc: dave.hansen@...ux.intel.com, linux-coco@...ts.linux.dev, 
	x86@...nel.org, linux-kernel@...r.kernel.org, vannapurve@...gle.com, 
	Elena Reshetova <elena.reshetova@...el.com>
Subject: Re: [RFC PATCH] /dev/mem: Disable /dev/mem under TDX guest

On Tue, Mar 18, 2025 at 01:36:04PM +0200, 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.

Crash of VMM or TD termination? If VMM crashes in this case, it has to be
fixed.

> 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.

I think it should lead to unrecoverable EPT-violation, but not VMM crash.

> Fix this by simply forbidding access to /dev/mem when running as an TDX
> guest.

I think we need to think wider. What about applying a subset of LOCKDOWN_*
in all coco guests by default. Many of them are relevant for the guest security.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov