Flavio Leitner <[email protected]> writes: > On Thu, Apr 18, 2019 at 10:43:11AM -0600, Alex Williamson wrote: >> On Thu, 18 Apr 2019 13:23:54 -0300 >> Flavio Leitner <[email protected]> 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 <[email protected]> >> > > --- >> > > 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. > > Ok, but if the machine has few cores, then the permission is set to > 0666 and I assumed that it was done by the module itself. Assuming > that it's true, then why can't the module fix the permission before? > > Another thing is that when the module is ready and the event is sent > out, what holds OVS for not trying to open and get EACCESS before > udev is triggered to fix the device permission?
The device is there from the start because of the MODULE_ALIAS and MODULE_ALIAS_MISCDEV properties; it gets created on the devfs before it's loaded. Then, on the first open() call, if it isn't loaded the misc chardev driver will block while loading the module. So from the start it's in existence. The VFS layer is what returns the EACCES, and that prevents the module load / blocking behavior we want. If OvS is running as root, because the device is 0600, then the module will get loaded. > fbl _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
