From: Yonghong Song <yhs@fb.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Jiri Olsa <jolsa@kernel.org>
Cc: "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 02:33:32 +0000 [thread overview]
Message-ID: <0e114cc9-421d-a30d-db40-91ec7a2a7a34@fb.com> (raw)
In-Reply-To: <CAADnVQKeR1VFEaRGY7Zy=P7KF8=TKshEy2inhFfi9qis9osS3A@mail.gmail.com>
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.
next prev parent reply other threads:[~2020-01-22 2:33 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 [this message]
2020-01-22 9:13 ` Jiri Olsa
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=0e114cc9-421d-a30d-db40-91ec7a2a7a34@fb.com \
--to=yhs@fb.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 \
/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;
as well as URLs for NNTP newsgroup(s).