[PATCH bpf-next 0/1] libbpf: fail early when loading programs with unspecified type

[PATCH bpf-next 0/1] libbpf: fail early when loading programs with unspecified type

[Andrei Matei]

This patch should help people who misunderstand the importance of using
proper prefixes to their ELF sections in bpf object files. The patch
assumes that programs with type BPF_PROG_TYPE_UNSPEC are always invalid,
as indicated by `man 2 bpf`. Please let me know if that is not accurate.

Andrei Matei (1):
  libbpf: fail early when loading programs with unspecified type

 tools/lib/bpf/libbpf.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

-- 
2.27.0

[PATCH bpf-next 1/1] libbpf: fail early when loading programs with unspecified type

[Andrei Matei]

Before this patch, a program with unspecified type
(BPF_PROG_TYPE_UNSPEC) would be passed to the BPF syscall, only to have
the kernel reject it with an opaque invalid argument error. This patch
makes libbpf reject such programs with a nicer error message - in
particular libbpf now tries to diagnose bad ELF section names at both
open time and load time.

Signed-off-by: Andrei Matei <andreimatei1@gmail.com>
---
 tools/lib/bpf/libbpf.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 313034117070..abca93b4f239 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -6629,6 +6629,18 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
 	char *log_buf = NULL;
 	int btf_fd, ret;
 
+	if (prog->type == BPF_PROG_TYPE_UNSPEC) {
+		if (!prog->sec_def) {
+			// We couldn't find a proper section definition at load time; that's probably why
+			// the program type is missing.
+			pr_warn("prog '%s': missing BPF prog type'; check ELF section name '%s'\n",
+					prog->name, prog->sec_name);
+		} else {
+			pr_warn("prog '%s': missing BPF prog type\n", prog->name);
+		}
+		return -EINVAL;
+	}
+
 	if (!insns || !insns_cnt)
 		return -EINVAL;
 
@@ -6920,9 +6932,11 @@ __bpf_object__open(const char *path, const void *obj_buf, size_t obj_buf_sz,
 
 	bpf_object__for_each_program(prog, obj) {
 		prog->sec_def = find_sec_def(prog->sec_name);
-		if (!prog->sec_def)
+		if (!prog->sec_def) {
 			/* couldn't guess, but user might manually specify */
+			pr_debug("prog '%s': unrecognized ELF section name '%s'\n", prog->name, prog->sec_name);
 			continue;
+    }
 
 		if (prog->sec_def->is_sleepable)
 			prog->prog_flags |= BPF_F_SLEEPABLE;
-- 
2.27.0

Re: [PATCH bpf-next 0/1] libbpf: fail early when loading programs with unspecified type

[Andrii Nakryiko]

On Mon, Nov 30, 2020 at 8:43 PM Andrei Matei <andreimatei1@gmail.com> wrote:
>
> This patch should help people who misunderstand the importance of using
> proper prefixes to their ELF sections in bpf object files. The patch
> assumes that programs with type BPF_PROG_TYPE_UNSPEC are always invalid,
> as indicated by `man 2 bpf`. Please let me know if that is not accurate.
>

FYI, you don't need to send a cover letter with a single patch.


> Andrei Matei (1):
>   libbpf: fail early when loading programs with unspecified type
>
>  tools/lib/bpf/libbpf.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> --
> 2.27.0
>

Re: [PATCH bpf-next 1/1] libbpf: fail early when loading programs with unspecified type

[Andrii Nakryiko]

On Mon, Nov 30, 2020 at 8:43 PM Andrei Matei <andreimatei1@gmail.com> wrote:
>
> Before this patch, a program with unspecified type
> (BPF_PROG_TYPE_UNSPEC) would be passed to the BPF syscall, only to have
> the kernel reject it with an opaque invalid argument error. This patch
> makes libbpf reject such programs with a nicer error message - in
> particular libbpf now tries to diagnose bad ELF section names at both
> open time and load time.
>
> Signed-off-by: Andrei Matei <andreimatei1@gmail.com>
> ---

This is useful, thanks. See below for a few comments, though.


>  tools/lib/bpf/libbpf.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 313034117070..abca93b4f239 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -6629,6 +6629,18 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
>         char *log_buf = NULL;
>         int btf_fd, ret;
>
> +       if (prog->type == BPF_PROG_TYPE_UNSPEC) {
> +               if (!prog->sec_def) {
> +                       // We couldn't find a proper section definition at load time; that's probably why
> +                       // the program type is missing.

no C++-style comments, please

> +                       pr_warn("prog '%s': missing BPF prog type'; check ELF section name '%s'\n",

extra ' after "prog type"? also ';' -> ',' ?

> +                                       prog->name, prog->sec_name);
> +               } else {
> +                       pr_warn("prog '%s': missing BPF prog type\n", prog->name);

while, technically, user can manually set program type to UNSPEC even
with good section name, that's probably extreme case which we
shouldn't worry about. So I'd just always emit the section name.

> +               }
> +               return -EINVAL;
> +       }
> +
>         if (!insns || !insns_cnt)
>                 return -EINVAL;
>
> @@ -6920,9 +6932,11 @@ __bpf_object__open(const char *path, const void *obj_buf, size_t obj_buf_sz,
>
>         bpf_object__for_each_program(prog, obj) {
>                 prog->sec_def = find_sec_def(prog->sec_name);
> -               if (!prog->sec_def)
> +               if (!prog->sec_def) {
>                         /* couldn't guess, but user might manually specify */
> +                       pr_debug("prog '%s': unrecognized ELF section name '%s'\n", prog->name, prog->sec_name);
>                         continue;
> +    }
>
>                 if (prog->sec_def->is_sleepable)
>                         prog->prog_flags |= BPF_F_SLEEPABLE;
> --
> 2.27.0
>