On 27/10/21 08:18, Tian, Kevin wrote:
I absolutely do *not* want an API that tells KVM to enable WBINVD.  This
is not up for discussion.

But really, let's stop calling the file descriptor a security proof or a
capability.  It's overkill; all that we are doing here is kernel
acceleration of the WBINVD ioctl.

As a thought experiment, let's consider what would happen if wbinvd
caused an unconditional exit from guest to userspace.  Userspace would
react by invoking the ioctl on the ioasid.  The proposed functionality
is just an acceleration of this same thing, avoiding the
guest->KVM->userspace->IOASID->wbinvd trip.

While the concept here makes sense, in reality implementing a wbinvd
ioctl for userspace requiring iommufd (previous /dev/ioasid is renamed
to /dev/iommu now) to track dirty CPUs that a given process has been
running since wbinvd only flushes local cache.

Is it ok to omit the actual wbinvd ioctl here and just leverage vfio-kvm
contract to manage whether guest wbinvd is emulated as no-op?

Yes, it'd be okay for me. As I wrote in the message, the concept of a wbinvd ioctl is mostly important as a thought experiment for what is security sensitive and what is not. If a wbinvd ioctl would not be privileged on the iommufd, then WBINVD is not considered privileged in a guest either.

That does not imply a requirement to implement the wbinvd ioctl, though. Of course, non-KVM usage of iommufd systems/devices with non-coherent DMA would be less useful; but that's already the case for VFIO.

btw does kvm community set a strict criteria that any operation that
the guest can do must be first carried in host uAPI first? In concept
KVM deals with ISA-level to cover both guest kernel and guest user
while host uAPI is only for host user. Introducing new uAPIs to allow
host user doing whatever guest kernel can do sounds ideal, but not
exactly necessary imho.

I agree; however, it's the right mindset in my opinion because virtualization (in a perfect world) should not be a way to give processes privilege to do something that they cannot do. If it does, it's usually a good idea to ask yourself "should this functionality be accessible outside KVM too?".

Thanks,

Paolo

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Reply via email to