linux-kernel - Re: [PATCH] bpf: fix incorrect initialization of bpf_ctx_convert

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]

Date:   Mon, 26 Oct 2020 15:32:48 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Arnd Bergmann <arnd@...nel.org>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Jakub Sitnicki <jakub@...udflare.com>,
        Arnd Bergmann <arnd@...db.de>, Martin KaFai Lau <kafai@...com>,
        Marek Majkowski <marek@...udflare.com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andrii@...nel.org>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>, Jiri Olsa <jolsa@...nel.org>,
        Alan Maguire <alan.maguire@...cle.com>,
        Hao Luo <haoluo@...gle.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] bpf: fix incorrect initialization of bpf_ctx_convert_map

On Mon, Oct 26, 2020 at 2:04 PM Arnd Bergmann <arnd@...nel.org> wrote:
>
> From: Arnd Bergmann <arnd@...db.de>
>
> gcc -Wextra points out that a field may get overridden in some
> configurations such as x86 allmodconfig, when the next index after the one
> that has been assigned last already had a value, in this case for index
> BPF_PROG_TYPE_SK_LOOKUP, which comes after BPF_PROG_TYPE_LSM in the list:
>
> kernel/bpf/btf.c:4225:2: warning: initialized field overwritten [-Woverride-init]
>  4225 |  0, /* avoid empty array */
>       |  ^
> kernel/bpf/btf.c:4225:2: note: (near initialization for 'bpf_ctx_convert_map[30]')
>
> Move the zero-initializer first instead. This avoids the warning since
> nothing else uses index 0, and the last element does not have to be zero.

Wouldn't it be cleaner and more explicit to add __MAX_BPF_PROG_TYPE to
enum bpf_prog_type in include/uapi/linux/bpf.h, similarly to how we do
it with enum bpf_attach_type? Then just specify the size of the array
here explicitly? Unless we are trying to save a few bytes for more
minimal configurations where some BPF program types are not used (but
still defined in an enum)?


>
> Fixes: e9ddbb7707ff ("bpf: Introduce SK_LOOKUP program type with a dedicated attach point")
> Fixes: 4c80c7bc583a ("bpf: Fix build in minimal configurations, again")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
>  kernel/bpf/btf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index ed7d02e8bc93..2a4a4aeeaac1 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -4218,11 +4218,11 @@ enum {
>         __ctx_convert_unused, /* to avoid empty enum in extreme .config */
>  };
>  static u8 bpf_ctx_convert_map[] = {
> +       [0] = 0, /* avoid empty array */
>  #define BPF_PROG_TYPE(_id, _name, prog_ctx_type, kern_ctx_type) \
>         [_id] = __ctx_convert##_id,
>  #include <linux/bpf_types.h>
>  #undef BPF_PROG_TYPE
> -       0, /* avoid empty array */
>  };
>  #undef BPF_MAP_TYPE
>  #undef BPF_LINK_TYPE
> --
> 2.27.0
>