Messages in this thread | | | Date | Wed, 27 Oct 2021 12:32:22 +0200 | Subject | Re: [RFC] /dev/ioasid uAPI proposal | From | Paolo Bonzini <> |
| |
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
| |