netdev - Re: [PATCH bpf-next 4/6] libbpf: add BPF_CORE_READ/BPF_CORE_READ

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: <346DCE18-FA64-40CA-86BD-C095935AC089@fb.com>
Date:   Tue, 1 Oct 2019 21:14:15 +0000
From:   Song Liu <songliubraving@...com>
To:     Andrii Nakryiko <andriin@...com>
CC:     bpf <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "andrii.nakryiko@...il.com" <andrii.nakryiko@...il.com>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 4/6] libbpf: add BPF_CORE_READ/BPF_CORE_READ_INTO
 helpers


> On Sep 30, 2019, at 11:58 AM, Andrii Nakryiko <andriin@...com> wrote:
> 
> Add few macros simplifying BCC-like multi-level probe reads, while also
> emitting CO-RE relocations for each read.
> 
> Signed-off-by: Andrii Nakryiko <andriin@...com>
> ---
> tools/lib/bpf/bpf_helpers.h | 151 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 147 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.h
> index a1d9b97b8e15..51e7b11d53e8 100644
> --- a/tools/lib/bpf/bpf_helpers.h
> +++ b/tools/lib/bpf/bpf_helpers.h
> @@ -19,6 +19,10 @@
>  */
> #define SEC(NAME) __attribute__((section(NAME), used))
> 
> +#ifndef __always_inline
> +#define __always_inline __attribute__((always_inline))
> +#endif
> +
> /* helper functions called from eBPF programs written in C */
> static void *(*bpf_map_lookup_elem)(void *map, const void *key) =
> 	(void *) BPF_FUNC_map_lookup_elem;
> @@ -505,7 +509,7 @@ struct pt_regs;
> #endif
> 
> /*
> - * BPF_CORE_READ abstracts away bpf_probe_read() call and captures offset
> + * bpf_core_read() abstracts away bpf_probe_read() call and captures field
>  * relocation for source address using __builtin_preserve_access_index()
>  * built-in, provided by Clang.
>  *
> @@ -520,8 +524,147 @@ struct pt_regs;
>  * actual field offset, based on target kernel BTF type that matches original
>  * (local) BTF, used to record relocation.
>  */
> -#define BPF_CORE_READ(dst, src)						\
> -	bpf_probe_read((dst), sizeof(*(src)),				\
> -		       __builtin_preserve_access_index(src))
> +#define bpf_core_read(dst, sz, src)					    \
> +	bpf_probe_read(dst, sz,						    \
> +		       (const void *)__builtin_preserve_access_index(src))
> +
> +/*
> + * bpf_core_read_str() is a thin wrapper around bpf_probe_read_str()
> + * additionally emitting BPF CO-RE field relocation for specified source
> + * argument.
> + */
> +#define bpf_core_read_str(dst, sz, src)					    \
> +	bpf_probe_read_str(dst, sz,					    \
> +			   (const void *)__builtin_preserve_access_index(src))
> +
> +#define ___concat(a, b) a ## b
> +#define ___apply(fn, n) ___concat(fn, n)
> +#define ___nth(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, __11, N, ...) N

We are adding many marcos with simple names: ___apply(), ___nth. So I worry
they may conflict with macro definitions from other libraries. Shall we hide
them in .c files or prefix/postfix them with _libbpf or something?

Thanks,
Song