netdev - Re: [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered

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: <CAEf4BzYeJxGuPC8rbsY5yvED8KNaq=7NULFPnwPdeEs==Srd1w@mail.gmail.com>
Date:   Thu, 30 Apr 2020 11:12:32 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Eelco Chaudron <echaudro@...hat.com>
Cc:     bpf <bpf@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin Lau <kafai@...com>, Song Liu <songliubraving@...com>,
        Yonghong Song <yhs@...com>, Andrii Nakryiko <andriin@...com>,
        Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered

On Thu, Apr 30, 2020 at 3:24 AM Eelco Chaudron <echaudro@...hat.com> wrote:
>
> When the probe code was failing for any reason ENOTSUP was returned, even
> if this was due to no having enough lock space. This patch fixes this by
> returning EPERM to the user application, so it can respond and increase
> the RLIMIT_MEMLOCK size.
>
> Signed-off-by: Eelco Chaudron <echaudro@...hat.com>
> ---
>  tools/lib/bpf/libbpf.c |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 8f480e29a6b0..a62388a151d4 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -3381,8 +3381,13 @@ bpf_object__probe_caps(struct bpf_object *obj)
>
>         for (i = 0; i < ARRAY_SIZE(probe_fn); i++) {
>                 ret = probe_fn[i](obj);
> -               if (ret < 0)
> +               if (ret < 0) {
>                         pr_debug("Probe #%d failed with %d.\n", i, ret);
> +                       if (ret == -EPERM) {
> +                               pr_perm_msg(ret);
> +                               return ret;

I think this is dangerous to do. This detection loop is not supposed
to return error to user if any of the features are missing. I'd feel
more comfortable if we split bpf_object__probe_name() into two tests:
one testing trivial program and another testing same program with
name. If the first one fails with EPERM -- then we can return error to
user. If anything else fails -- that's ok. Thoughts?

> +                       }
> +               }
>         }
>
>         return 0;
>