On Thu, 18 Apr 2019 13:23:54 -0300
Flavio Leitner <f...@sysclose.org> wrote:

> On Thu, Apr 18, 2019 at 11:05:28AM -0400, Aaron Conole wrote:
> > On some systems, it's possible that the initialization of the misc chardev
> > associated with /dev/vfio/vfio is delayed.  This happens on machines with
> > large numbers of cores (at least 88+).  If this delay exceeds the time
> > required for ovs-vswitchd to call the dpdk initialization routine, the
> > permissions won't be updated and the open call will return EACCES.
> > 
> > To fix this, we explicitly allow global open.  This means any user may
> > open() the vfio device before the vfio modules are initialized, thus
> > triggering a module load.  The applications (including ovs-vswitchd)
> > would be pended while the module loads.  This should be safe, as any user
> > may open the vfio device once the module is loaded anyway, since the.
> > module rewrites the permissions as 0666.
> > 
> > Signed-off-by: Aaron Conole <acon...@redhat.com>
> > ---
> >  rhel/usr_lib_udev_rules.d_91-vfio.rules | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/rhel/usr_lib_udev_rules.d_91-vfio.rules 
> > b/rhel/usr_lib_udev_rules.d_91-vfio.rules
> > index 8e34b2a2b..c0504ab5a 100644
> > --- a/rhel/usr_lib_udev_rules.d_91-vfio.rules
> > +++ b/rhel/usr_lib_udev_rules.d_91-vfio.rules
> > @@ -1 +1,2 @@
> >  ACTION=="add", SUBSYSTEM=="vfio*", GROUP="hugetlbfs", MODE="0660"
> > +ACTION=="add", SUBSYSTEM=="misc", KERNEL=="vfio", MODE="0666"  
> 
> Wouldn't be better to fix this at the module to fix the permissions
> before whatever is taking long to initialize?

The stronger security policy is to not allow unprivileged users to
trigger an operation which loads a module, so no, upper level system
policy should relax that as necessary, but not the module.  VFIO is
unavailable until enabled through privileged entities, so there's some
degree that ovs is "jumping the gun" in making use of it, afaict.
Thanks,

Alex
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to