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

2017-07-11 Thread Aaron Conole
Aaron Conole  writes:

> Aaron Conole  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.
>

UPDATE: it seems that with DPDK 17.02+, this has been resolved.  I'll
wait for resubmit until after the following commit has been applied:

https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/334893.html

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


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

2017-07-07 Thread Aaron Conole

Aaron Conole  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
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev