From: Jiri Olsa <jolsa@redhat.com>
To: Yonghong Song <yhs@fb.com>
Cc: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>,
"Jiri Olsa" <jolsa@kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"John Fastabend" <john.fastabend@gmail.com>,
"Network Development" <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, "Andrii Nakryiko" <andriin@fb.com>,
"Martin Lau" <kafai@fb.com>,
"Jakub Kicinski" <jakub.kicinski@netronome.com>,
"David Miller" <davem@redhat.com>,
"Björn Töpel" <bjorn.topel@intel.com>
Subject: Re: [PATCH 1/6] bpf: Allow ctx access for pointers to scalar
Date: Wed, 22 Jan 2020 10:13:36 +0100 [thread overview]
Message-ID: <20200122091336.GE801240@krava> (raw)
In-Reply-To: <0e114cc9-421d-a30d-db40-91ec7a2a7a34@fb.com>
On Wed, Jan 22, 2020 at 02:33:32AM +0000, Yonghong Song wrote:
>
>
> On 1/21/20 5:51 PM, Alexei Starovoitov wrote:
> > On Tue, Jan 21, 2020 at 4:05 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >>
> >> When accessing the context we allow access to arguments with
> >> scalar type and pointer to struct. But we omit pointer to scalar
> >> type, which is the case for many functions and same case as
> >> when accessing scalar.
> >>
> >> Adding the check if the pointer is to scalar type and allow it.
> >>
> >> Acked-by: John Fastabend <john.fastabend@gmail.com>
> >> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> >> ---
> >> kernel/bpf/btf.c | 13 ++++++++++++-
> >> 1 file changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> >> index 832b5d7fd892..207ae554e0ce 100644
> >> --- a/kernel/bpf/btf.c
> >> +++ b/kernel/bpf/btf.c
> >> @@ -3668,7 +3668,7 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type,
> >> const struct bpf_prog *prog,
> >> struct bpf_insn_access_aux *info)
> >> {
> >> - const struct btf_type *t = prog->aux->attach_func_proto;
> >> + const struct btf_type *tp, *t = prog->aux->attach_func_proto;
> >> struct bpf_prog *tgt_prog = prog->aux->linked_prog;
> >> struct btf *btf = bpf_prog_get_target_btf(prog);
> >> const char *tname = prog->aux->attach_func_name;
> >> @@ -3730,6 +3730,17 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type,
> >> */
> >> return true;
> >>
> >> + tp = btf_type_by_id(btf, t->type);
> >> + /* skip modifiers */
> >> + while (btf_type_is_modifier(tp))
> >> + tp = btf_type_by_id(btf, tp->type);
> >> +
> >> + if (btf_type_is_int(tp) || btf_type_is_enum(tp))
> >> + /* This is a pointer scalar.
> >> + * It is the same as scalar from the verifier safety pov.
> >> + */
> >> + return true;
> >
> > The reason I didn't do it earlier is I was thinking to represent it
> > as PTR_TO_BTF_ID as well, so that corresponding u8..u64
> > access into this memory would still be possible.
> > I'm trying to analyze the situation that returning a scalar now
> > and converting to PTR_TO_BTF_ID in the future will keep progs
> > passing the verifier. Is it really the case?
> > Could you give a specific example that needs this support?
> > It will help me understand this backward compatibility concern.
> > What prog is doing with that 'u32 *' that is seen as scalar ?
> > It cannot dereference it. Use it as what?
>
> If this is from original bcc code, it will use bpf_probe_read for
> dereference. This is what I understand when I first reviewed this patch.
> But it will be good to get Jiri's confirmation.
it blocked me from accessing 'filename' argument when I probed
do_sys_open via trampoline in bcc, like:
KRETFUNC_PROBE(do_sys_open)
{
const char *filename = (const char *) args[1];
AFAICS the current code does not allow for trampoline arguments
being other pointers than to void or struct, the patch should
detect that the argument is pointer to scalar type and let it
pass
jirka
next prev parent reply other threads:[~2020-01-22 9:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 12:05 [PATCHv3 0/6] bpf: Add trampoline helpers Jiri Olsa
2020-01-21 12:05 ` [PATCH 1/6] bpf: Allow ctx access for pointers to scalar Jiri Olsa
2020-01-22 1:51 ` Alexei Starovoitov
2020-01-22 2:33 ` Yonghong Song
2020-01-22 9:13 ` Jiri Olsa [this message]
2020-01-22 16:09 ` Alexei Starovoitov
2020-01-22 21:18 ` Jiri Olsa
2020-01-23 1:16 ` Alexei Starovoitov
2020-01-21 12:05 ` [PATCH 2/6] bpf: Add bpf_perf_event_output_kfunc Jiri Olsa
2020-01-22 0:03 ` Alexei Starovoitov
2020-01-22 7:51 ` Jiri Olsa
2020-01-21 12:05 ` [PATCH 3/6] bpf: Add bpf_get_stackid_kfunc Jiri Olsa
2020-01-21 12:05 ` [PATCH 4/6] bpf: Add bpf_get_stack_kfunc Jiri Olsa
2020-01-21 12:05 ` [PATCH 5/6] bpf: Allow to resolve bpf trampoline and dispatcher in unwind Jiri Olsa
2020-01-21 12:05 ` [PATCH 6/6] selftest/bpf: Add test for allowed trampolines count Jiri Olsa
2020-01-22 0:10 ` Alexei Starovoitov
2020-01-22 7:47 ` Jiri Olsa
-- strict thread matches above, loose matches on Subject: below --
2020-01-18 13:49 [PATCHv2 0/6] bpf: Add trampoline helpers Jiri Olsa
2020-01-18 13:49 ` [PATCH 1/6] bpf: Allow ctx access for pointers to scalar Jiri Olsa
2020-01-21 0:24 ` John Fastabend
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=20200122091336.GE801240@krava \
--to=jolsa@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@redhat.com \
--cc=jakub.kicinski@netronome.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--cc=yhs@fb.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