netdev - Re: [PATCH bpf-next 0/8] PROG_TEST_RUN support for sk

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: <76aa7c94-939f-b370-0ff0-03af3865c5f9@iogearbox.net>
Date:   Wed, 24 Feb 2021 22:37:17 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Lorenz Bauer <lmb@...udflare.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Jakub Sitnicki <jakub@...udflare.com>,
        kernel-team <kernel-team@...udflare.com>,
        bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf-next 0/8] PROG_TEST_RUN support for sk_lookup programs

On 2/23/21 8:29 AM, Andrii Nakryiko wrote:
> On Tue, Feb 16, 2021 at 2:58 AM Lorenz Bauer <lmb@...udflare.com> wrote:
>>
>> We don't have PROG_TEST_RUN support for sk_lookup programs at the
>> moment. So far this hasn't been a problem, since we can run our
>> tests in a separate network namespace. For benchmarking it's nice
>> to have PROG_TEST_RUN, so I've gone and implemented it.
>>
>> Multiple sk_lookup programs can be attached at once to the same
>> netns. This can't be expressed with the current PROG_TEST_RUN
>> API, so I'm proposing to extend it with an array of prog_fd.
>>
>> Patches 1-2 are clean ups. Patches 3-4 add the new UAPI and
>> implement PROG_TEST_RUN for sk_lookup. Patch 5 adds a new
>> function to libbpf to access multi prog tests. Patches 6-8 add
>> tests.
>>
>> Andrii, for patch 4 I decided on the following API:
>>
>>      int bpf_prog_test_run_array(__u32 *prog_fds, __u32 prog_fds_cnt,
>>                                  struct bpf_test_run_opts *opts)
>>
>> To be consistent with the rest of libbpf it would be better
>> to take int *prog_fds, but I think then the function would have to
>> convert the array to account for platforms where
>>
>>      sizeof(int) != sizeof(__u32)
> 
> Curious, is there any supported architecture where this is not the
> case? I think it's fine to be consistent, tbh, and use int. Worst
> case, in some obscure architecture we'd need to create a copy of an
> array. Doesn't seem like a big deal (and highly unlikely anyways).

Given __u32 are kernel UAPI exported types for user space (e.g. used in
syscall APIs), you can check where / how they are defined. Mainly here:

   include/uapi/asm-generic/int-l64.h:27:typedef unsigned int __u32;
   include/uapi/asm-generic/int-ll64.h:27:typedef unsigned int __u32;

Thanks,
Daniel