netdev - Re: [PATCH bpf] bpf: Support sk lookup in netns with id 0

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOftzPiPgp-b5PPH5wiytgg+W-b5qrz-krjDoyhPnJoNcgJRpg@mail.gmail.com>
Date:   Tue, 27 Nov 2018 10:01:40 -0800
From:   Joe Stringer <joe@...d.net.nz>
To:     Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc:     David Ahern <dsahern@...il.com>, Joe Stringer <joe@...d.net.nz>,
        daniel@...earbox.net, ast@...nel.org,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf] bpf: Support sk lookup in netns with id 0

On Tue, 27 Nov 2018 at 06:49, Nicolas Dichtel <nicolas.dichtel@...nd.com> wrote:
>
> Le 26/11/2018 à 23:08, David Ahern a écrit :
> > On 11/26/18 2:27 PM, Joe Stringer wrote:
> >> @@ -2405,6 +2407,9 @@ enum bpf_func_id {
> >>  /* BPF_FUNC_perf_event_output for sk_buff input context. */
> >>  #define BPF_F_CTXLEN_MASK           (0xfffffULL << 32)
> >>
> >> +/* BPF_FUNC_sk_lookup_tcp and BPF_FUNC_sk_lookup_udp flags. */
> >> +#define BPF_F_SK_CURRENT_NS         0x80000000 /* For netns field */
> >> +
> >
> > I went down the nsid road because it will be needed for other use cases
> > (e.g., device lookups), and we should have a general API for network
> > namespaces. Given that, I think the _SK should be dropped from the name.

Fair point, I'll drop _SK from the name

> >
> Would it not be possible to have a s32 instead of an u32 for the coming APIs?
> It would be better to match the current netlink and kernel APIs.

Sure, I'll look into this.

I had earlier considered whether it's worth attempting to leave the
upper 32 bits of this parameter open for potential future expansion,
but at this point I'm not taking that into consideration. If anyone
has preferences or thoughts on that I'd be interested to hear them.