From: Matt Bobrowski <mattbobrowski@google.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, song@kernel.org, kpsingh@kernel.org,
sdf@google.com, haoluo@google.com, memxor@gmail.com,
void@manifault.com, jolsa@kernel.org
Subject: Re: [PATCH 1/2] bpf: relax zero fixed offset constraint on trusted pointer arguments
Date: Tue, 18 Jun 2024 07:12:16 +0000 [thread overview]
Message-ID: <ZnEzULLoRfjYqOin@google.com> (raw)
In-Reply-To: <28250a9a52c8a10dc7c37e15df9a9d446976e4eb.camel@gmail.com>
Hey Eduard,
Thank you for taking a look at this patch series, much appreciated.
On Mon, Jun 17, 2024 at 10:38:56PM -0700, Eduard Zingerman wrote:
> On Mon, 2024-06-17 at 13:43 +0000, Matt Bobrowski wrote:
>
> [...]
>
> > * For OBJ_RELEASE and KF_RELEASE BPF helpers and kfuncs:
> >
> > * If the expected argument type is of an untyped pointer i.e. void *,
> > then we continue to enforce a zero fixed offset as we need to
> > ensure that the correct referenced pointer is handed off correctly
> > to the relevant deallocation routine
> >
> > * If the expected argument is backed by BTF, then we relax the strict
> > zero fixed offset and allow it only if we successfully type matched
> > between the register and argument. A failed type match between
> > register and argument will result in the legacy strict zero offset
> > semantics
> >
> > * For KF_TRUSTED_ARGS BPF kfuncs:
> >
> > * The fixed zero offset constraint has been lifted, such that
> > KF_TRUSTED_ARGS BPF kfuncs can now accept a trusted pointer
> > argument with a non-zero fixed offset providing that register and
> > argument BTF has type matched successfully
>
> [...]
>
> Hi Matt,
>
> I've read this and the next patch once, but need more time to provide
> feedback. Two quick notes:
> - It seems something is wrong with the way this patch set was sent:
> for some reason it is not organized as a single thread (e.g. on vger).
Yeah, I don't know what happened there, I must've screwed something up
whilst sending out the patches. The process I use to send these
patches out is rather manual ATM, so I should probably look to revamp
it so I can avoid such hiccups. Apologies about this, but the V2
edition of this patch series will come through structured as intended,
I promise.
> - I see how OBJ_RELEASE arguments trigger btf_struct_ids_match() in
> check_release_arg_reg_off(), but I don't see how KF_TRUSTED_ARGS
> trigger similar logic.
Right, the btf_struct_ids_match() is done at a slightly later point
from within process_kf_arg_ptr_to_btf_id().
> Do you have some positive tests that verify newly added functionality?
The only positive test which demonstrates this new usability
improvement can be seen in the BPF program test_nested_offset, which
I've also included within this patch in:
* tools/testing/selftests/bpf/progs/nested_trust_success.c
The test_nested_offset BPF program is effectively a positively
converted version of the test_invalid_nested_offset BPF program which
resided in:
* tools/testing/selftests/bpf/progs/nested_trust_failure.c
Maybe I could look at some other positive tests too, but the above was
an immediate and obvious candidate. I also intend to post out another
patch series which adds a bunch of new BPF kfuncs. These new BPF
kfuncs will basically piggyback and rely on this new relaxed register
fixed offset checking, so we'll get some implicit positive test
coverage there too I guess.
/M
next prev parent reply other threads:[~2024-06-18 7:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 13:43 [PATCH 1/2] bpf: relax zero fixed offset constraint on trusted pointer arguments Matt Bobrowski
2024-06-18 5:38 ` Eduard Zingerman
2024-06-18 7:12 ` Matt Bobrowski [this message]
2024-06-19 8:57 ` Kumar Kartikeya Dwivedi
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=ZnEzULLoRfjYqOin@google.com \
--to=mattbobrowski@google.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=memxor@gmail.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=void@manifault.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