> From: Tian, Kevin > Sent: Tuesday, March 30, 2021 10:24 AM > > > From: Jason Gunthorpe <j...@nvidia.com> > > Sent: Tuesday, March 30, 2021 12:32 AM > > > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host > > > mm, > > > the use case is as the following: > > > > From that doc: > > > > It is imperative to enforce > > VM-IOASID ownership such that a malicious guest cannot target DMA > > traffic outside its own IOASIDs, or free an active IOASID that belongs > > to another VM. > > > > Huh? > > > > Security in a PASID world comes from the IOMMU blocking access to the > > PASID except from approved PCI-ID's. If a VF/PF is assigned to a guest > > then that guest can cause the device to issue any PASID by having > > complete control and the vIOMMU is supposed to tell the real IOMMU > > what PASID's the device is alowed to access. > > > > If a device is sharing a single PCI function with different security > > contexts (eg vfio mdev) then the device itself is responsible to > > ensure that only the secure interface can program a PASID and a less > > secure context can never self-enroll. > > > > Here the mdev driver would have to consule with the vIOMMU to ensure > > the mdev device is allowed to access the PASID - is that what this > > set stuff is about? > > > > If yes, it is backwards. The MDEV is the thing doing the security, the > > MDEV should have the list of allowed PASID's and a single PASID > > created under /dev/ioasid should be loaded into MDEV with some 'Ok you > > can use PASID xyz from FD abc' command. > > > > The 'set' is per-VM. Once the mdev is assigned to a VM, all valid PASID's > in the set of that VM are considered legitimate on this mdev. The mdev > driver will mediate guest operations which program PASID to the backend > context and load the PASID only if it is within the 'set' (i.e. already > allocated through /dev/ioasid). This prevents a malicious VM from attacking > others. Though it's not mdev which directly maintaining the list of allowed > PASID's, the effect is the same in concept. >
One correction. The mdev should still construct the list of allowed PASID's as you said (by listening to IOASID_BIND/UNBIND event), in addition to the ioasid set maintained per VM (updated when a PASID is allocated/freed). The per-VM set is required for inter-VM isolation (verified when a pgtable is bound to the mdev/PASID), while the mdev's own list is necessary for intra-VM isolation when multiple mdevs are assigned to the same VM (verified before loading a PASID to the mdev). This series just handles the general part i.e. per-VM ioasid set and leaves the mdev's own list to be managed by specific mdev driver which listens to various IOASID events). Thanks Kevin
