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

[Juergen Gross <jgross@suse.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1935 bytes --]

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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]