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

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