netdev - RE: [PATCH bpf-next v7 04/13] bpf: Add support for forcing kfunc args to be trusted

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: <64f5b92546c14b69a20e9007bb31146b@huawei.com>
Date:   Mon, 25 Jul 2022 09:52:07 +0000
From:   Roberto Sassu <roberto.sassu@...wei.com>
To:     Kumar Kartikeya Dwivedi <memxor@...il.com>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>
CC:     Alexei Starovoitov <ast@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Florian Westphal <fw@...len.de>,
        "Jesper Dangaard Brouer" <brouer@...hat.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>
Subject: RE: [PATCH bpf-next v7 04/13] bpf: Add support for forcing kfunc args
 to be trusted

> From: Kumar Kartikeya Dwivedi [mailto:memxor@...il.com]
> Sent: Thursday, July 21, 2022 3:43 PM
> Teach the verifier to detect a new KF_TRUSTED_ARGS kfunc flag, which
> means each pointer argument must be trusted, which we define as a
> pointer that is referenced (has non-zero ref_obj_id) and also needs to
> have its offset unchanged, similar to how release functions expect their
> argument. This allows a kfunc to receive pointer arguments unchanged
> from the result of the acquire kfunc.
> 
> This is required to ensure that kfunc that operate on some object only
> work on acquired pointers and not normal PTR_TO_BTF_ID with same type
> which can be obtained by pointer walking. The restrictions applied to
> release arguments also apply to trusted arguments. This implies that
> strict type matching (not deducing type by recursively following members
> at offset) and OBJ_RELEASE offset checks (ensuring they are zero) are
> used for trusted pointer arguments.
> 
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@...il.com>
> ---
>  include/linux/btf.h | 32 ++++++++++++++++++++++++++++++++
>  kernel/bpf/btf.c    | 17 ++++++++++++++---
>  net/bpf/test_run.c  |  5 +++++
>  3 files changed, 51 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/btf.h b/include/linux/btf.h
> index 6dfc6eaf7f8c..cb63aa71e82f 100644
> --- a/include/linux/btf.h
> +++ b/include/linux/btf.h
> @@ -17,6 +17,38 @@
>  #define KF_RELEASE	(1 << 1) /* kfunc is a release function */
>  #define KF_RET_NULL	(1 << 2) /* kfunc returns a pointer that may be NULL */
>  #define KF_KPTR_GET	(1 << 3) /* kfunc returns reference to a kptr */
> +/* Trusted arguments are those which are meant to be referenced arguments
> with
> + * unchanged offset. It is used to enforce that pointers obtained from acquire
> + * kfuncs remain unmodified when being passed to helpers taking trusted args.
> + *
> + * Consider
> + *	struct foo {
> + *		int data;
> + *		struct foo *next;
> + *	};
> + *
> + *	struct bar {
> + *		int data;
> + *		struct foo f;
> + *	};
> + *
> + *	struct foo *f = alloc_foo(); // Acquire kfunc
> + *	struct bar *b = alloc_bar(); // Acquire kfunc
> + *
> + * If a kfunc set_foo_data() wants to operate only on the allocated object, it
> + * will set the KF_TRUSTED_ARGS flag, which will prevent unsafe usage like:
> + *
> + *	set_foo_data(f, 42);	   // Allowed
> + *	set_foo_data(f->next, 42); // Rejected, non-referenced pointer
> + *	set_foo_data(&f->next, 42);// Rejected, referenced, but bad offset
> + *	set_foo_data(&b->f, 42);   // Rejected, referenced, but wrong type
> + *
> + * In the final case, usually for the purposes of type matching, it is deduced
> + * by looking at the type of the member at the offset, but due to the
> + * requirement of trusted argument, this deduction will be strict and not done
> + * for this case.
> + */
> +#define KF_TRUSTED_ARGS (1 << 4) /* kfunc only takes trusted pointer
> arguments */

Hi Kumar

would it make sense to introduce per-parameter flags? I have a function
that has several parameters, but only one is referenced.

Thanks

Roberto