From: David Vernet <void@manifault.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@kernel.org>,
Joanne Koong <joannelkoong@gmail.com>
Subject: Re: [PATCH bpf-next v1 01/13] bpf: Refactor ARG_PTR_TO_DYNPTR checks into process_dynptr_func
Date: Wed, 19 Oct 2022 10:26:29 -0500 [thread overview]
Message-ID: <Y1AXJdisetkYvwpB@maniforge.dhcp.thefacebook.com> (raw)
In-Reply-To: <20221019060412.dqvq2e23cuh3jw52@apollo>
On Wed, Oct 19, 2022 at 11:34:12AM +0530, Kumar Kartikeya Dwivedi wrote:
> On Wed, Oct 19, 2022 at 01:15:37AM IST, David Vernet wrote:
> > On Tue, Oct 18, 2022 at 07:29:08PM +0530, Kumar Kartikeya Dwivedi wrote:
> >
> > Hey Kumar, thanks for looking at this stuff.
> >
> > > ARG_PTR_TO_DYNPTR is akin to ARG_PTR_TO_TIMER, ARG_PTR_TO_KPTR, where
> > > the underlying register type is subjected to more special checks to
> > > determine the type of object represented by the pointer and its state
> > > consistency.
> > >
> > > Move dynptr checks to their own 'process_dynptr_func' function so that
> > > is consistent and in-line with existing code. This also makes it easier
> > > to reuse this code for kfunc handling.
> >
> > Just out of curiosity, do you have a specific use case for when you'd envision
> > a kfunc taking a dynptr? I'm not saying there are none, just curious if you
> > have any specifically that you've considered.
> >
>
> There is already a kfunc that takes dynptrs, bpf_verify_pkcs7_signature. I am
> sure we'll get more in the future.
Ah, ok, hence why the negative-selftest you removed called that kfunc
with a ringbuf dynptr.
> > > To this end, remove the dependency on bpf_call_arg_meta parameter by
> > > instead taking the uninit_dynptr_regno by pointer. This is only needed
> > > to be set to a valid pointer when arg_type has MEM_UNINIT.
> > >
> > > Then, reuse this consolidated function in kfunc dynptr handling too.
> > > Note that for kfuncs, the arg_type constraint of DYNPTR_TYPE_LOCAL has
> > > been lifted.
> > >
> > > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> > > ---
> > > include/linux/bpf_verifier.h | 8 +-
> > > kernel/bpf/btf.c | 17 +--
> > > kernel/bpf/verifier.c | 115 ++++++++++--------
> > > .../bpf/prog_tests/kfunc_dynptr_param.c | 5 +-
> > > .../bpf/progs/test_kfunc_dynptr_param.c | 12 --
> > > 5 files changed, 69 insertions(+), 88 deletions(-)
> > >
> > > diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> > > index 9e1e6965f407..a33683e0618b 100644
> > > --- a/include/linux/bpf_verifier.h
> > > +++ b/include/linux/bpf_verifier.h
> > > @@ -593,11 +593,9 @@ int check_kfunc_mem_size_reg(struct bpf_verifier_env *env, struct bpf_reg_state
> > > u32 regno);
> > > int check_mem_reg(struct bpf_verifier_env *env, struct bpf_reg_state *reg,
> > > u32 regno, u32 mem_size);
> > > -bool is_dynptr_reg_valid_init(struct bpf_verifier_env *env,
> > > - struct bpf_reg_state *reg);
> > > -bool is_dynptr_type_expected(struct bpf_verifier_env *env,
> > > - struct bpf_reg_state *reg,
> > > - enum bpf_arg_type arg_type);
> > > +int process_dynptr_func(struct bpf_verifier_env *env, int regno,
> > > + enum bpf_arg_type arg_type, int argno,
> > > + u8 *uninit_dynptr_regno);
> > >
> > > /* this lives here instead of in bpf.h because it needs to dereference tgt_prog */
> > > static inline u64 bpf_trampoline_compute_key(const struct bpf_prog *tgt_prog,
> > > diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> > > index eba603cec2c5..1827d889e08a 100644
> > > --- a/kernel/bpf/btf.c
> > > +++ b/kernel/bpf/btf.c
> > > @@ -6486,23 +6486,8 @@ static int btf_check_func_arg_match(struct bpf_verifier_env *env,
> > > return -EINVAL;
> > > }
> > >
> > > - if (!is_dynptr_reg_valid_init(env, reg)) {
> > > - bpf_log(log,
> > > - "arg#%d pointer type %s %s must be valid and initialized\n",
> > > - i, btf_type_str(ref_t),
> > > - ref_tname);
> > > + if (process_dynptr_func(env, regno, ARG_PTR_TO_DYNPTR, i, NULL))
> > > return -EINVAL;
> > > - }
> >
> > Could you please clarify why you're removing the DYNPTR_TYPE_LOCAL constraint
> > for kfuncs?
> >
> > You seemed to have removed the following negative selftest:
> >
> > > -SEC("?lsm.s/bpf")
> > > -int BPF_PROG(dynptr_type_not_supp, int cmd, union bpf_attr *attr,
> > > - unsigned int size)
> > > -{
> > > - char write_data[64] = "hello there, world!!";
> > > - struct bpf_dynptr ptr;
> > > -
> > > - bpf_ringbuf_reserve_dynptr(&ringbuf, sizeof(write_data), 0, &ptr);
> > > -
> > > - return bpf_verify_pkcs7_signature(&ptr, &ptr, NULL);
> > > -}
> > > -
> >
> > But it was clearly the intention of the test validate that we can't pass a
> > dynptr to a ringbuf region to this kfunc, so I'm curious what's changed since
> > that test was added.
> >
>
> There was no inherent limitation for just accepting local dynptrs, it's that
> when this was added I suggested sticking to one kind back then, because of the
> code divergence between kfunc argument checking and helper argument checking.
>
> Now that both share the same code, it's easier to handle everything one place
> and make it work everywhere the same way.
>
> Also, next patch adds a very clear distinction between argument type which only
> operates on the dynamically sized memory slice and ones which may also modify
> dynptr, which also makes it easier to support things for kfuncs by setting
> MEM_RDONLY.
Makes sense, thanks for clarifying.
> > > -
> > > - if (!is_dynptr_type_expected(env, reg,
> > > - ARG_PTR_TO_DYNPTR | DYNPTR_TYPE_LOCAL)) {
> > > - bpf_log(log,
> > > - "arg#%d pointer type %s %s points to unsupported dynamic pointer type\n",
> > > - i, btf_type_str(ref_t),
> > > - ref_tname);
> > > - return -EINVAL;
> > > - }
> > > -
> > > continue;
> > > }
> > >
> > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > index 6f6d2d511c06..31c0c999448e 100644
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -782,8 +782,7 @@ static bool is_dynptr_reg_valid_uninit(struct bpf_verifier_env *env, struct bpf_
> > > return true;
> > > }
> > >
> > > -bool is_dynptr_reg_valid_init(struct bpf_verifier_env *env,
> > > - struct bpf_reg_state *reg)
> > > +static bool is_dynptr_reg_valid_init(struct bpf_verifier_env *env, struct bpf_reg_state *reg)
> > > {
> > > struct bpf_func_state *state = func(env, reg);
> > > int spi = get_spi(reg->off);
> > > @@ -802,9 +801,8 @@ bool is_dynptr_reg_valid_init(struct bpf_verifier_env *env,
> > > return true;
> > > }
> > >
> > > -bool is_dynptr_type_expected(struct bpf_verifier_env *env,
> > > - struct bpf_reg_state *reg,
> > > - enum bpf_arg_type arg_type)
> > > +static bool is_dynptr_type_expected(struct bpf_verifier_env *env, struct bpf_reg_state *reg,
> > > + enum bpf_arg_type arg_type)
> > > {
> > > struct bpf_func_state *state = func(env, reg);
> > > enum bpf_dynptr_type dynptr_type;
> > > @@ -5573,6 +5571,65 @@ static int process_kptr_func(struct bpf_verifier_env *env, int regno,
> > > return 0;
> > > }
> > >
> > > +int process_dynptr_func(struct bpf_verifier_env *env, int regno,
> > > + enum bpf_arg_type arg_type, int argno,
> > > + u8 *uninit_dynptr_regno)
> > > +{
> >
> > IMO 'process' is a bit too generic of a term. If we decide to go with this,
> > what do you think about changing the name to check_func_dynptr_arg(), or just
> > check_dynptr_arg()?
> >
>
> While I agree, then it would be different from the existing ones and look a bit
> odd in the list (e.g. process_spin_lock, process_kptr_func, etc.). So I am not
> very sure, but if you still feel it's better I don't mind.
Uniformity should trump my own personal preferences. We can stick with
process_dynptr_func().
LGTM, thanks for answering my questions.
Acked-by: David Vernet <void@manifault.com>
next prev parent reply other threads:[~2022-10-19 15:34 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 13:59 [PATCH bpf-next v1 00/13] Fixes for dynptr Kumar Kartikeya Dwivedi
2022-10-18 13:59 ` [PATCH bpf-next v1 01/13] bpf: Refactor ARG_PTR_TO_DYNPTR checks into process_dynptr_func Kumar Kartikeya Dwivedi
2022-10-18 19:45 ` David Vernet
2022-10-19 6:04 ` Kumar Kartikeya Dwivedi
2022-10-19 15:26 ` David Vernet [this message]
2022-10-19 22:59 ` Joanne Koong
2022-10-20 0:55 ` Kumar Kartikeya Dwivedi
2022-10-18 13:59 ` [PATCH bpf-next v1 02/13] bpf: Rework process_dynptr_func Kumar Kartikeya Dwivedi
2022-10-18 23:16 ` David Vernet
2022-10-19 6:18 ` Kumar Kartikeya Dwivedi
2022-10-19 16:05 ` David Vernet
2022-10-20 1:09 ` Kumar Kartikeya Dwivedi
2022-10-18 13:59 ` [PATCH bpf-next v1 03/13] bpf: Rename confusingly named RET_PTR_TO_ALLOC_MEM Kumar Kartikeya Dwivedi
2022-10-18 21:38 ` sdf
2022-10-19 6:19 ` Kumar Kartikeya Dwivedi
2022-11-07 22:35 ` Joanne Koong
2022-11-07 23:12 ` Kumar Kartikeya Dwivedi
2022-10-18 13:59 ` [PATCH bpf-next v1 04/13] bpf: Rework check_func_arg_reg_off Kumar Kartikeya Dwivedi
2022-10-18 21:55 ` sdf
2022-10-19 6:24 ` Kumar Kartikeya Dwivedi
2022-11-07 23:17 ` Joanne Koong
2022-11-08 18:22 ` Kumar Kartikeya Dwivedi
2022-10-18 13:59 ` [PATCH bpf-next v1 05/13] bpf: Fix state pruning for STACK_DYNPTR stack slots Kumar Kartikeya Dwivedi
2022-11-08 20:22 ` Joanne Koong
2022-11-09 18:39 ` Kumar Kartikeya Dwivedi
2022-11-10 0:41 ` Joanne Koong
2022-10-18 13:59 ` [PATCH bpf-next v1 06/13] bpf: Fix missing var_off check for ARG_PTR_TO_DYNPTR Kumar Kartikeya Dwivedi
2022-10-19 18:52 ` Alexei Starovoitov
2022-10-20 1:04 ` Kumar Kartikeya Dwivedi
2022-10-20 2:13 ` Alexei Starovoitov
2022-10-20 2:40 ` Kumar Kartikeya Dwivedi
2022-10-20 2:56 ` Alexei Starovoitov
2022-10-20 3:23 ` Kumar Kartikeya Dwivedi
2022-10-21 0:46 ` Alexei Starovoitov
2022-10-21 1:53 ` Kumar Kartikeya Dwivedi
2022-10-18 13:59 ` [PATCH bpf-next v1 07/13] bpf: Fix partial dynptr stack slot reads/writes Kumar Kartikeya Dwivedi
2022-10-21 22:50 ` Joanne Koong
2022-10-21 22:57 ` Joanne Koong
2022-10-22 4:08 ` Kumar Kartikeya Dwivedi
2022-11-03 14:07 ` Joanne Koong
2022-11-04 22:14 ` Andrii Nakryiko
2022-11-04 23:02 ` Kumar Kartikeya Dwivedi
2022-11-04 23:08 ` Andrii Nakryiko
2022-10-18 13:59 ` [PATCH bpf-next v1 08/13] bpf: Use memmove for bpf_dynptr_{read,write} Kumar Kartikeya Dwivedi
2022-10-21 18:12 ` Joanne Koong
2022-10-18 13:59 ` [PATCH bpf-next v1 09/13] selftests/bpf: Add test for dynptr reinit in user_ringbuf callback Kumar Kartikeya Dwivedi
2022-10-19 16:59 ` David Vernet
2022-10-18 13:59 ` [PATCH bpf-next v1 10/13] selftests/bpf: Add dynptr pruning tests Kumar Kartikeya Dwivedi
2022-10-18 13:59 ` [PATCH bpf-next v1 11/13] selftests/bpf: Add dynptr var_off tests Kumar Kartikeya Dwivedi
2022-10-18 13:59 ` [PATCH bpf-next v1 12/13] selftests/bpf: Add dynptr partial slot overwrite tests Kumar Kartikeya Dwivedi
2022-10-18 13:59 ` [PATCH bpf-next v1 13/13] selftests/bpf: Add dynptr helper tests Kumar Kartikeya Dwivedi
2023-10-31 7:05 ` CVE-2023-39191 - Dynptr fixes - reg Nandhini Rengaraj
2023-10-31 7:13 ` Greg KH
2023-10-31 7:57 ` Shung-Hsi Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1AXJdisetkYvwpB@maniforge.dhcp.thefacebook.com \
--to=void@manifault.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=joannelkoong@gmail.com \
--cc=martin.lau@kernel.org \
--cc=memxor@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox