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

[Nikolay Borisov]

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@xxxxxxxx>
> > ---
> >
> > 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