RE: [PATCH v2 3/3] iommufd/vdevice: add TSM guest request ioctl

[Tian, Kevin]

> From: Williams, Dan J <dan.j.williams@xxxxxxxxx>
> Sent: Saturday, March 14, 2026 6:18 AM
> 
> Jason Gunthorpe wrote:
> > On Mon, Mar 09, 2026 at 04:47:04PM +0530, Aneesh Kumar K.V (Arm)
> wrote:
> > > +/**
> > > + * struct iommu_vdevice_tsm_guest_request -
> ioctl(IOMMU_VDEVICE_TSM_GUEST_REQUEST)
> > > + * @size: sizeof(struct iommu_vdevice_tsm_guest_request)
> > > + * @vdevice_id: vDevice ID the guest request is for
> > > + * @scope: scope of tsm guest request
> > > + * @req_len: the blob size for @req_uptr, filled by guest
> > > + * @resp_len: the blob size for @resp_uptr, filled by guest
> > > + * @req_uptr: request data buffer filled by guest
> > > + * @resp_uptr: response data buffer
> > > + */
> >
> > This needs a much better kdoc.
> >
> > Refer to specs that define this.
> >
> > Explain WTF scope is
> 
> I proposed @scope, yes this needs more documentation, but really it
> needs more discussion first. It was inspired by 'enum fwctl_rpc_scope'
> 
> Guests that are moving the device through the TDISP setup state machine
> need to ask for host services because only the host passes messages over
> SPDM in all of these architectures. That is, one SPDM session per
> physical device, not per assigned virtual function. In the AMD case
> there is less guest direct access to the TSM so it needs to pass
> additional messages that the CPU mode based TSMs do not.
> 
> Those requests are varying degrees of: host kernel cares, host kernel
> does not care but can see the contents of the message, and host kernel
> does not care and can not see the contents of the message beyond
> envelope.

"host kernel cares" means that the host kernel may check CAP_SYS_RAW_IO
or taint itself to limit commands according to the description of
enum pci_tsm_req_scope?

interestingly commit c316c75d57fb ("PCI/TSM: Add pci_tsm_guest_req()
for managing TDIs ") has the following description:

"
    This path is purely a transport for messages from TVM to platform TSM. By
    design the host kernel does not and must not care about the content of
    these messages. I.e. the host kernel is not in the TCB of the TVM.
"

how to associate "must not care" with above "host kernel cares"?

> 
> As far as the host kernel security model is concerned this becomes a
> opaque implementation specific passthrough. So the role of @scope is to
> have the TSM drivers declare the security model for various messages.
> Put the explicit onus on the implmentations to declare that the
> guest_request operation being executed in response to a KVM exit is
> contained within a given security scope. See 'enum pci_tsm_req_scope'.

dumb question - what about a malicious userspace specifies a scope 
with a smaller value than what's defined for a request? Would (could) the
tsm driver verify that it’s a wrong value (but if it can then why we need
this field at all)?