| 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
| ||
|
Message-ID: <CAEf4Bzaj-t0UYLiJh9czenqVtsi5UuviX_AqgpEq=gJx6WCHrw@mail.gmail.com>
Date: Thu, 18 Jun 2020 21:29:58 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Jiri Olsa <jolsa@...nel.org>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Martin KaFai Lau <kafai@...com>,
David Miller <davem@...hat.com>,
John Fastabend <john.fastabend@...il.com>,
Wenbo Zhang <ethercflow@...il.com>,
KP Singh <kpsingh@...omium.org>,
Andrii Nakryiko <andriin@...com>,
Brendan Gregg <bgregg@...flix.com>,
Florent Revest <revest@...omium.org>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH 08/11] bpf: Add BTF whitelist support
On Tue, Jun 16, 2020 at 3:06 AM Jiri Olsa <jolsa@...nel.org> wrote:
>
> Adding support to define 'whitelist' of BTF IDs, which is
> also sorted.
>
> Following defines sorted list of BTF IDs that is accessible
> within kernel code as btf_whitelist_d_path and its count is
> in btf_whitelist_d_path_cnt variable.
>
> extern int btf_whitelist_d_path[];
> extern int btf_whitelist_d_path_cnt;
>
> BTF_WHITELIST_ENTRY(btf_whitelist_d_path)
> BTF_ID(func, vfs_truncate)
> BTF_ID(func, vfs_fallocate)
> BTF_ID(func, dentry_open)
> BTF_ID(func, vfs_getattr)
> BTF_ID(func, filp_close)
> BTF_WHITELIST_END(btf_whitelist_d_path)
>
> Signed-off-by: Jiri Olsa <jolsa@...nel.org>
> ---
> include/linux/bpf.h | 3 +++
> kernel/bpf/btf.c | 13 +++++++++++++
> kernel/bpf/btf_ids.h | 38 ++++++++++++++++++++++++++++++++++++++
> kernel/bpf/verifier.c | 5 +++++
> 4 files changed, 59 insertions(+)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index e98c113a5d27..a94e85c2ec50 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -283,6 +283,7 @@ struct bpf_func_proto {
> enum bpf_arg_type arg_type[5];
> };
> int *btf_id; /* BTF ids of arguments */
> + bool (*allowed)(const struct bpf_prog *prog);
> };
>
> /* bpf_context is intentionally undefined structure. Pointer to bpf_context is
> @@ -1745,6 +1746,8 @@ enum bpf_text_poke_type {
> int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type t,
> void *addr1, void *addr2);
>
> +bool btf_whitelist_search(int id, int list[], int cnt);
> +
> extern int bpf_skb_output_btf_ids[];
> extern int bpf_seq_printf_btf_ids[];
> extern int bpf_seq_write_btf_ids[];
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 6924180a19c4..feda74d232c5 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -20,6 +20,7 @@
> #include <linux/btf.h>
> #include <linux/skmsg.h>
> #include <linux/perf_event.h>
> +#include <linux/bsearch.h>
> #include <net/sock.h>
>
> /* BTF (BPF Type Format) is the meta data format which describes
> @@ -4669,3 +4670,15 @@ u32 btf_id(const struct btf *btf)
> {
> return btf->id;
> }
> +
> +static int btf_id_cmp_func(const void *a, const void *b)
> +{
> + const int *pa = a, *pb = b;
> +
> + return *pa - *pb;
> +}
> +
> +bool btf_whitelist_search(int id, int list[], int cnt)
whitelist is a bit too specific, this functionality can be used for
blacklisting as well, no?
How about instead of "open coding" separately int list[] + int cnt, we
define a struct:
struct btf_id_set {
u32 cnt;
u32 ids[];
};
and pass that around?
This function then can be generic
bool btf_id_set_contains(struct btf_id_set *set, u32 id);
Then it's usable for both whitelist and blacklist? _contains also
clearly implies what's the return result, while _search isn't so clear
in that regard.
> +{
> + return bsearch(&id, list, cnt, sizeof(int), btf_id_cmp_func) != NULL;
> +}
> diff --git a/kernel/bpf/btf_ids.h b/kernel/bpf/btf_ids.h
> index 68aa5c38a37f..a90c09faa515 100644
> --- a/kernel/bpf/btf_ids.h
> +++ b/kernel/bpf/btf_ids.h
> @@ -67,4 +67,42 @@ asm( \
> #name ":; \n" \
> ".popsection; \n");
>
> +
> +/*
> + * The BTF_WHITELIST_ENTRY/END macros pair defines sorted
> + * list of BTF IDs plus its members count, with following
> + * layout:
> + *
> + * BTF_WHITELIST_ENTRY(list2)
> + * BTF_ID(type1, name1)
> + * BTF_ID(type2, name2)
> + * BTF_WHITELIST_END(list)
It kind of sucks you need two separate ENTRY/END macro (btw, START/END
or BEGIN/END would be a bit more "paired"), and your example clearly
shows why: it is not self-consistent (list2 on start, list on end ;).
But doing variadic macro like this would be a nightmare as well,
unfortunately. :(
> + *
> + * __BTF_ID__sort__list:
> + * list2_cnt:
> + * .zero 4
> + * list2:
> + * __BTF_ID__type1__name1__3:
> + * .zero 4
> + * __BTF_ID__type2__name2__4:
> + * .zero 4
> + *
> + */
> +#define BTF_WHITELIST_ENTRY(name) \
> +asm( \
> +".pushsection " SECTION ",\"a\"; \n" \
> +".global __BTF_ID__sort__" #name "; \n" \
> +"__BTF_ID__sort__" #name ":; \n" \
I mentioned in the previous patch already, I think "sort" is a bad
name, consider "set" (or "list", but you used list name already for a
slightly different macro).
> +".global " #name "_cnt; \n" \
> +#name "_cnt:; \n" \
This label/symbol isn't necessary, why polluting the symbol table?
> +".zero 4 \n" \
> +".popsection; \n"); \
> +BTF_ID_LIST(name)
> +
> +#define BTF_WHITELIST_END(name) \
> +asm( \
> +".pushsection " SECTION ",\"a\"; \n" \
> +".size __BTF_ID__sort__" #name ", .-" #name " \n" \
> +".popsection; \n");
> +
> #endif
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index bee3da2cd945..5a9a6fd72907 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -4633,6 +4633,11 @@ static int check_helper_call(struct bpf_verifier_env *env, int func_id, int insn
> return -EINVAL;
> }
>
> + if (fn->allowed && !fn->allowed(env->prog)) {
> + verbose(env, "helper call is not allowed in probe\n");
nit: probe -> program, or just drop "in probe" part altogether
> + return -EINVAL;
> + }
> +
> /* With LD_ABS/IND some JITs save/restore skb from r1. */
> changes_data = bpf_helper_changes_pkt_data(fn->func);
> if (changes_data && fn->arg1_type != ARG_PTR_TO_CTX) {
> --
> 2.25.4
>
Powered by blists - more mailing lists