Re: [PATCH v6 0/6] x86/tdx: Allow MMIO instructions from userspace

[Sean Christopherson <seanjc@google.com>]

On Fri, Sep 13, 2024, Dave Hansen wrote:
> On 9/13/24 09:28, Sean Christopherson wrote:
> >> because folks would update their kernel and old userspace would break.
> >>
> >> Or maybe we start enforcing things at >=SEV-SNP and TDX and just say
> >> that security model has changed too much to allow the old userspace.
> > Heh, that's an outright lie though.  Nothing relevant has changed between SEV-ES
> > and SEV-SNP that makes old userspace any less secure, or makes it harder for the
> > kernel to support decoding instructions on SNP vs. ES.
> 
> The trust model does change, though.
> 
> The VMM is still in the guest TCB for SEV-ES because there are *so* many
> ways to leverage NPT to compromise a VM.  Yeah, the data isn't in plain
> view of the VMM, but that doesn't mean the VMM is out of the TCB.
> 
> With SEV-ES, old crusty userspace is doing MMIO to a VMM in the TCB.
> 
> With SEV-SNP, old crusty userspace is talking to an untrusted VMM.
> 
> I think that's how the security model changes.

I agree to some extent, but as below, this really only holds true if we're talking
about old crusty userspace.  And even then, it's weird to draw the line at the
emulated MMIO boundary, because if crusty old userspace is a security risk, then
the kernel arguably shouldn't have mapped the MMIO address into that userspace in
the first place.

> > I also don't know that this is for old userspace.  AFAIK, the most common case
> > for userspace triggering emulated MMIO is when a device is passed to userspace
> > via VFIO/IOMMUFD, e.g. a la DPDK.
> 
> Ahh, that would make sense.
> 
> It would be nice to hear from those folks _somewhere_ about what their
> restrictions are and if they'd ever be able to enforce a subset of the
> ISA for MMIO or even (for example) make system calls to do MMIO.
> 
> Does it matter to them if all of a sudden the NIC or the NVMe device on
> the other side of VFIO is malicious?