[dpdk-dev] [ovs-dev] [PATCH v2 0/4] rhel/fedora: non-root OvS out of the box

[Aaron Conole]

Aaron Conole <aconole at redhat.com> writes:

> This series attempts to introduce the ability to start and use
> Open vSwitch 'out of the box' as a non-root user.  It does this by
> modifying the service files to pass the recently introduced --ovs-user
> argument around, and by making some minor tweaks to the passwd, group,
> and filesystem information.
>
> I prefixed the packaging work with 'redhat', but if rpm or packaging
> is a preferred prefx for that work, I can respin.
>
> The more controversial changes are:
>
> * This modifies the /etc/sysconfig/ file on install.
> * The dpdk support directly modifies /dev/hugepages with a call to chmod
> * A new user 'openvswitch', and up to two new groups 'openvswitch', and
>   'hugetlbfs' are created
> * A change to soexpand.pl to allow conditional inclusion of dpdk-related
>   options
>

An interesting development has occurred while testing this series.

It seems that as part of a rowhammer mitigation, access to
/proc/self/pagemap ends up being restricted.  This makes DPDK break in a
catastrophic way.

One way of mitigating this is to keep the CAP_SYS_ADMIN capability when
DPDK is enabled (not sure whether it would be a runtime or compile
time change).  This means we end up keeping many root-user level
permissions that we probably shouldn't need or want.  I was thinking
that when DPDK is compiled in, we would keep the CAP_SYS_ADMIN for the
first iteration of DB synchronization, and then drop it after calling
DPDK-init.  That would prevent lazy loading, or being able to turn it
on without restarting the daemon (which I don't like).

Another is to say that if DPDK is enabled at compile time, just don't
drop permissions at all.  That approach seems really wrong, but it's a
possibility.

Not sure what else can be done from the OvS side for this.  I think it
could be possible to do something where before dropping privs, we cache
the pagemap and then feed it to DPDK during initialization, but that
will require work from DPDK side, and I'm not sure if it actually works
with DPDK (because I haven't looked into why the pagemap is being read
to begin with).

So, I'm a bit stuck on this work, and asking for some opinions.

-Aaron