Re: [RFC] /dev/ioasid uAPI proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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"




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux