Messages in this thread | | | Subject | Re: [RFC] /dev/ioasid uAPI proposal | From | Paolo Bonzini <> | Date | Fri, 4 Jun 2021 17:57:19 +0200 |
| |
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.
Paolo
> 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 > > #1 is an improvement because it allows userspace to enable wbinvd and > no-snoop optimizations based on user choice > > #2 is where we are today and wbinvd effectively becomes a fixed > platform choice. Userspace has no say > > #3 is "there is a problem, but not so serious, root is powerful > enough to override"
| |