public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
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>

  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