On Wed, Jun 09, 2021 at 08:31:34AM -0600, Alex Williamson wrote: > If we go back to the wbinvd ioctl mechanism, if I call that ioctl with > an ioasidfd that contains no devices, then I shouldn't be able to > generate a wbinvd on the processor, right? If I add a device, > especially in a configuration that can generate non-coherent DMA, now > that ioctl should work. If I then remove all devices from that ioasid, > what then is the difference from the initial state. Should the ioctl > now work because it worked once in the past? The ioctl is fine, but telling KVM to enable WBINVD is very similar to open and then reconfiguring the ioasid_fd is very similar to chmod. From a security perspective revoke is not strictly required, IMHO. > access. This is no different than starting a shell via sudo (ie. an > ongoing reference) or having the previous authentication time out, or > in our case be notified it has expired. Those are all authentication gates as well, yes sudo has a timer, but once the timer expires it doesn't forcibly revoke & close all the existing sudo sessions. It just means you can't create new ones without authenticating. > > > That's already more or less meaningless for both KVM and VFIO, since they > > > are tied to an mm. > > > > vfio isn't supposed to be tied to a mm. > > vfio does accounting against an mm, why shouldn't it be tied to an mm? It looks like vfio type 1 is doing it properly, each ranch of of user VA is stuffed into a struct vfio_dma and that contains a struct task (which can be a mm_struct these days) that refers to the owning mm. Looks like a single fd can hold multiple vfio_dma's and I don't see an enforcment that current is locked to any specific process. When the accounting is done it is done via the mm obtained through the vfio_dma struct, not a global FD wide mm. This appears all fine for something using pin_user_pages(). We don't expect FDs to become locked to a single process on the first call to pin_user_pages() that is un-unixy. kvm is special in this regard. Jason
