netdev - Re: [PATCH bpf-next v3 5/6] libbpf: Add bpf_get_link_xdp_info() function to get more XDP information

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 for Android: free password hash cracker in your pocket

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

Date:   Sat, 09 Nov 2019 21:18:12 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        David Miller <davem@...emloft.net>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next v3 5/6] libbpf: Add bpf_get_link_xdp_info() function to get more XDP information

Andrii Nakryiko <andrii.nakryiko@...il.com> writes:

> On Sat, Nov 9, 2019 at 3:20 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>>
>> Andrii Nakryiko <andrii.nakryiko@...il.com> writes:
>>
>> > On Fri, Nov 8, 2019 at 4:01 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>> >>
>> >> From: Toke Høiland-Jørgensen <toke@...hat.com>
>> >>
>> >> Currently, libbpf only provides a function to get a single ID for the XDP
>> >> program attached to the interface. However, it can be useful to get the
>> >> full set of program IDs attached, along with the attachment mode, in one
>> >> go. Add a new getter function to support this, using an extendible
>> >> structure to carry the information. Express the old bpf_get_link_id()
>> >> function in terms of the new function.
>> >>
>> >> Acked-by: David S. Miller <davem@...emloft.net>
>> >> Acked-by: Song Liu <songliubraving@...com>
>> >> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
>> >> ---
>> >>  tools/lib/bpf/libbpf.h   |   10 ++++++
>> >>  tools/lib/bpf/libbpf.map |    1 +
>> >>  tools/lib/bpf/netlink.c  |   82 ++++++++++++++++++++++++++++++----------------
>> >>  3 files changed, 65 insertions(+), 28 deletions(-)
>> >>
>> >
>> > [...]
>> >
>> >>
>> >> -int bpf_get_link_xdp_id(int ifindex, __u32 *prog_id, __u32 flags)
>> >> +int bpf_get_link_xdp_info(int ifindex, struct xdp_link_info *info,
>> >> +                         size_t info_size, __u32 flags)
>> >>  {
>> >>         struct xdp_id_md xdp_id = {};
>> >>         int sock, ret;
>> >>         __u32 nl_pid;
>> >>         __u32 mask;
>> >>
>> >> -       if (flags & ~XDP_FLAGS_MASK)
>> >> +       if (flags & ~XDP_FLAGS_MASK || info_size < sizeof(*info))
>> >>                 return -EINVAL;
>> >
>> > Well, now it's backwards-incompatible: older program passes smaller
>> > (but previously perfectly valid) sizeof(struct xdp_link_info) to newer
>> > version of libbpf. This has to go both ways: smaller struct should be
>> > supported as long as program doesn't request (using flags) something,
>> > that can't be put into allowed space.
>>
>> But there's nothing to be backwards-compatible with? I get that *when*
>> we extend the size of xdp_link_info, we should still accept the old,
>> smaller size. But in this case that cannot happen as we're only just
>> introducing this now?
>
> This seems like a shifting burden to next person that will have to
> extend this, but ok, fine by me.

Well, there's a good chance that this could be myself ;)

However, in this case, since it's just a getter, and we're already doing
size checks on how much data we memcpy back, I suppose that we don't
actually need any minimum size at all, do we (well, apart from a check
for 0)? We can just always copy whatever size the caller passes in, and
they'll just get whatever portion of the struct that happens to be?

-Toke