Messages in this thread | | | Date | Fri, 4 Jun 2021 13:03:36 -0300 | From | Jason Gunthorpe <> | Subject | Re: [RFC] /dev/ioasid uAPI proposal |
| |
On Fri, Jun 04, 2021 at 05:57:19PM +0200, Paolo Bonzini wrote: > On 04/06/21 17:50, Jason Gunthorpe wrote: > > > Extending the scenarios where WBINVD is not a nop is not a problem for me. > > > If possible I wouldn't mind keeping the existing kvm-vfio connection via the > > > device, if only because then the decision remains in the VFIO camp (whose > > > judgment I trust more than mine on this kind of issue). > > Really the question to answer is what "security proof" do you want > > before the wbinvd can be enabled > > I don't want a security proof myself; I want to trust VFIO to make the right > judgment and I'm happy to defer to it (via the KVM-VFIO device). > > Given how KVM is just a device driver inside Linux, VMs should be a slightly > more roundabout way to do stuff that is accessible to bare metal; not a way > to gain extra privilege.
Okay, fine, lets turn the question on its head then.
VFIO should provide a IOCTL VFIO_EXECUTE_WBINVD so that userspace VFIO application can make use of no-snoop optimizations. The ability of KVM to execute wbinvd should be tied to the ability of that IOCTL to run in a normal process context.
So, under what conditions do we want to allow VFIO to giave a process elevated access to the CPU:
> > 1) User has access to a device that can issue no-snoop TLPS > > 2) User has access to an IOMMU that can not block no-snoop (today) > > 3) Require CAP_SYS_RAW_IO > > 4) Anyone
Jason
| |