lkml.org 
[lkml]   [2021]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2021-06-04 18:03    [W:5.225 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site