linux-kernel - Re: [PATCH bpf-next v2 1/3] bpf: sock ops: add netns ino and dev in bpf context

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: <CAH3MdRUiXrVwHKHb-XuQffrDAEZHovjxCvRtQ69J-=_L=FX2Ng@mail.gmail.com>
Date:   Fri, 19 Apr 2019 15:59:04 -0700
From:   Y Song <ys114321@...il.com>
To:     Alban Crequy <alban@...volk.io>
Cc:     Alban Crequy <alban.crequy@...il.com>,
        John Fastabend <john.fastabend@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        bpf <bpf@...r.kernel.org>, netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Iago López Galeiras <iago@...volk.io>
Subject: Re: [PATCH bpf-next v2 1/3] bpf: sock ops: add netns ino and dev in
 bpf context

On Fri, Apr 19, 2019 at 4:51 AM Alban Crequy <alban@...volk.io> wrote:
>
> On Thu, Apr 18, 2019 at 11:31 PM Y Song <ys114321@...il.com> wrote:
> >
> > On Thu, Apr 18, 2019 at 8:58 AM Alban Crequy <alban.crequy@...il.com> wrote:
> > >
> > > From: Alban Crequy <alban@...volk.io>
> > >
> > > sockops programs can now access the network namespace inode and device
> > > via (struct bpf_sock_ops)->netns_ino and ->netns_dev. This can be useful
> > > to apply different policies on different network namespaces.
> > >
> > > In the unlikely case where network namespaces are not compiled in
> > > (CONFIG_NET_NS=n), the verifier will not allow access to ->netns_*.
> > >
> > > The generated BPF bytecode for netns_ino is loading the correct inode
> > > number at the time of execution.
> > >
> > > However, the generated BPF bytecode for netns_dev is loading an
> > > immediate value determined at BPF-load-time by looking at the initial
> > > network namespace. In practice, this works because all netns currently
> > > use the same virtual device. If this was to change, this code would need
> > > to be updated too.
> > >
> > > Signed-off-by: Alban Crequy <alban@...volk.io>
> > >
> > > ---
> > >
> > > Changes since v1:
> > > - add netns_dev (review from Alexei)
> > > ---
> > >  include/uapi/linux/bpf.h |  2 ++
> > >  net/core/filter.c        | 70 ++++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 72 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > index eaf2d3284248..f4f841dde42c 100644
> > > --- a/include/uapi/linux/bpf.h
> > > +++ b/include/uapi/linux/bpf.h
> > > @@ -3213,6 +3213,8 @@ struct bpf_sock_ops {
> > >         __u32 sk_txhash;
> > >         __u64 bytes_received;
> > >         __u64 bytes_acked;
> > > +       __u64 netns_dev;
> > > +       __u64 netns_ino;
> >
> > Maybe we can define netns_dev as __u32?
> >    __u64 netns_ino;
> >    __u32 netns_dev;
> >
> > There is a hole at the end which can be used if the next
> > field to be added in the future is a __u32.
> >
> > From
> > static inline u32 new_encode_dev(dev_t dev)
> > {
> >         unsigned major = MAJOR(dev);
> >         unsigned minor = MINOR(dev);
> >         return (minor & 0xff) | (major << 8) | ((minor & ~0xff) << 12);
> > }
> >
> > device num is encoded in a u32.
>
> I could do that but there are already two occurrences of "__u64
> netns_dev" in bpf.h:
> - struct bpf_prog_info
> - struct bpf_map_info
>
> Should I keep it a u64 for consistency with the rest of bpf.h, or
> change it to u32?

Agreed. We probably should keep it to be __u64 to be consistent with others.