netdev - Re: [RFC v2 net-next 03/12] libbpf: api for getting/setting link xdp options

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: <CAEf4Bza=AT5NcBkQnJucgY5+QfkQTVX_S2CfiV6o6p_oGrr=ng@mail.gmail.com>
Date:   Sun, 29 Dec 2019 20:49:52 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Prashant Bhole <prashantbhole.linux@...il.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Jason Wang <jasowang@...hat.com>,
        David Ahern <dsahern@...il.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        John Fastabend <john.fastabend@...il.com>,
        Toshiaki Makita <toshiaki.makita1@...il.com>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        Networking <netdev@...r.kernel.org>
Subject: Re: [RFC v2 net-next 03/12] libbpf: api for getting/setting link xdp options

On Wed, Dec 25, 2019 at 6:34 PM Prashant Bhole
<prashantbhole.linux@...il.com> wrote:
>
> This patch introduces and uses new APIs:
>
> struct bpf_link_xdp_opts {
>         struct xdp_link_info *link_info;
>         size_t link_info_sz;
>         __u32 flags;
>         __u32 prog_id;
>         int prog_fd;
> };

Please see the usage of DECLARE_LIBBPF_OPTS and OPTS_VALID/OPTS_GET
(e.g., in bpf_object__open_file). This also seems like a rather
low-level API, so might be more appropriate to follow the naming of
low-level API in bpf.h (see Andrey Ignatov's recent
bpf_prog_attach_xattr() changes).

As is this is not backwards/forward compatible, unless you use
LIBBPF_OPTS approach (that's what Alexei meant).


>
> enum bpf_link_cmd {
>         BPF_LINK_GET_XDP_INFO,
>         BPF_LINK_GET_XDP_ID,
>         BPF_LINK_SET_XDP_FD,
> };
>
> int bpf_get_link_opts(int ifindex, struct bpf_link_xdp_opts *opts,
>                       enum bpf_link_cmd cmd);
> int bpf_set_link_opts(int ifindex, struct bpf_link_xdp_opts *opts,
>                       enum bpf_link_cmd cmd);
>
> The operations performed by these two functions are equivalent to
> existing APIs.
>
> BPF_LINK_GET_XDP_ID equivalent to bpf_get_link_xdp_id()
> BPF_LINK_SET_XDP_FD equivalent to bpf_set_link_xdp_fd()
> BPF_LINK_GET_XDP_INFO equivalent to bpf_get_link_xdp_info()
>
> It will be easy to extend this API by adding members in struct
> bpf_link_xdp_opts and adding different operations. Next patch
> will extend this API to set XDP program in the tx path.

Not really, and this has been extensively discussed previously. One of
the problems is old user code linked against newer libbpf version
(shared library). New libbpf will assume struct with more fields,
while old user code will provide too short struct. That's why all the
LIBBPF_OPTS stuff.

>
> Signed-off-by: Prashant Bhole <prashantbhole.linux@...il.com>
> ---
>  tools/lib/bpf/libbpf.h   | 36 +++++++++++++++++++
>  tools/lib/bpf/libbpf.map |  2 ++
>  tools/lib/bpf/netlink.c  | 77 ++++++++++++++++++++++++++++++++++++----
>  3 files changed, 109 insertions(+), 6 deletions(-)
>

[...]