netdev - Re: [PATCH v4 net] bpf: add bpf_sk_netns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87tw7u4x41.fsf@xmission.com>
Date:   Thu, 16 Feb 2017 16:45:34 +1300
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     David Ahern <dsa@...ulusnetworks.com>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Alexei Starovoitov <ast@...com>,
        "David S . Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Tejun Heo <tj@...nel.org>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH v4 net] bpf: add bpf_sk_netns_id() helper

David Ahern <dsa@...ulusnetworks.com> writes:

> On 2/15/17 8:25 PM, Andy Lutomirski wrote:
>> On Wed, Feb 15, 2017 at 7:18 PM, David Ahern <dsa@...ulusnetworks.com> wrote:
>>> On 2/15/17 8:08 PM, Eric W. Biederman wrote:
>>>> David Ahern <dsa@...ulusnetworks.com> writes:
>>>>
>>>>> On 2/14/17 12:21 AM, Eric W. Biederman wrote:
>>>>>>> in cases where bpf programs are looking at sockets and packets
>>>>>>> that belong to different netns, it could be useful to get an id
>>>>>>> that uniquely identify a netns within the whole system.
>>>>>> It could be useful but there is no unique namespace id.
>>>>>>
>>>>>
>>>>> Have you given thought to a unique namespace id? Networking tracepoints
>>>>> for example could really benefit from a unique id.
>>>>
>>>> An id from the perspective of a process in the initial instance of every
>>>> namespace is certainly possible.
>>>>
>>>> A truly unique id is just not maintainable.  Think of the question how
>>>> do you assign every device in the world a rguaranteed unique ip address
>>>> without coordination, that is routable.  It is essentially the same
>>>> problem.
>>>>
>>>> AKA it is theoretically possible and very expensive.  It is much easier
>>>> and much more maintainable for identifiers to have scope and only be
>>>> unique within that scope.
>>>
>>>
>>> I don't mean unique in the entire world, I mean unique within a single
>>> system.
>>>
>>> Tracepoints are code based and have global scope. I would like to be
>>> able to correlate, for example, FIB lookups within a single network
>>> namespace. Having an id that I could filter on when collecting or match
>>> when dumping them goes a long way.
>> 
>> Why wouldn't an id relative to your logging program work?  Global ids
>> are problematic because they are incompatible with tools like CRIU.
>> 
>
> How would that work?
>
> To be specific with an example, I only want FIB lookups for network
> namespace "foo". The name "foo" only has meaning for iproute2, so I need
> something the kernel understands. Should that be a dev/inode match
> meaning the tracepoints contain the netns dev and inode?
>
> From a perf perspective, the command line is like this:
>    perf record -e fib:fib_table_lookup --filter="netns_dev == 3 &&
> netns_ino == 4026531957" -a -g -- sleep 5
>
> Cumbersome, but it would work if the tracepoints had netns_dev and
> netns_ino as variables. A single id would be better.

A netns_dev_ino variable perhaps?  Something that you could pass a netns
file descriptor to perf and perf would just sort out the rest?

I believe those are just tooling issues.

The practical issue with one id that is global everywhere is that it has
to work for checkpoint/restart.   At which point it truly has to be
globably unique or namespaced.

Eric