[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <48d5c3df-8735-4aa9-afe3-bfcd32f7cfe8@linux.alibaba.com>
Date: Sat, 7 Sep 2024 11:26:49 +0800
From: Philo Lu <lulie@...ux.alibaba.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: bpf@...r.kernel.org, edumazet@...gle.com, rostedt@...dmis.org,
mhiramat@...nel.org, mathieu.desnoyers@...icios.com, martin.lau@...ux.dev,
ast@...nel.org, daniel@...earbox.net, andrii@...nel.org, eddyz87@...il.com,
song@...nel.org, yonghong.song@...ux.dev, john.fastabend@...il.com,
kpsingh@...nel.org, sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org,
davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, mykolal@...com,
shuah@...nel.org, mcoquelin.stm32@...il.com, alexandre.torgue@...s.st.com,
thinker.li@...il.com, juntong.deng@...look.com, jrife@...gle.com,
alan.maguire@...cle.com, davemarchevsky@...com, dxu@...uu.xyz,
vmalik@...hat.com, cupertino.miranda@...cle.com, mattbobrowski@...gle.com,
xuanzhuo@...ux.alibaba.com, netdev@...r.kernel.org,
linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 1/5] bpf: Support __nullable argument suffix
for tp_btf
On 2024/9/7 05:25, Andrii Nakryiko wrote:
> On Thu, Sep 5, 2024 at 12:56 AM Philo Lu <lulie@...ux.alibaba.com> wrote:
>>
>> Pointers passed to tp_btf were trusted to be valid, but some tracepoints
>> do take NULL pointer as input, such as trace_tcp_send_reset(). Then the
>> invalid memory access cannot be detected by verifier.
>>
>> This patch fix it by add a suffix "__nullable" to the unreliable
>> argument. The suffix is shown in btf, and PTR_MAYBE_NULL will be added
>> to nullable arguments. Then users must check the pointer before use it.
>>
>> A problem here is that we use "btf_trace_##call" to search func_proto.
>> As it is a typedef, argument names as well as the suffix are not
>> recorded. To solve this, I use bpf_raw_event_map to find
>> "__bpf_trace##template" from "btf_trace_##call", and then we can see the
>> suffix.
>>
>> Suggested-by: Alexei Starovoitov <ast@...nel.org>
>> Signed-off-by: Philo Lu <lulie@...ux.alibaba.com>
>> ---
>> kernel/bpf/btf.c | 13 +++++++++++++
>> kernel/bpf/verifier.c | 36 +++++++++++++++++++++++++++++++++---
>> 2 files changed, 46 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index 1e29281653c62..157f5e1247c81 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>> @@ -6385,6 +6385,16 @@ static bool prog_args_trusted(const struct bpf_prog *prog)
>> }
>> }
>>
>> +static bool prog_arg_maybe_null(const struct bpf_prog *prog, const struct btf *btf,
>> + const struct btf_param *arg)
>> +{
>> + if (prog->type != BPF_PROG_TYPE_TRACING ||
>> + prog->expected_attach_type != BPF_TRACE_RAW_TP)
>> + return false;
>> +
>> + return btf_param_match_suffix(btf, arg, "__nullable");
>
> why does this need to be BPF_TRACE_RAW_TP-specific logic? Are we
> afraid that there might be "some_arg__nullable" argument name?..
>
Yes. I don't think the check is necessary but I'm not quite sure if it
affects other prog/attach types. It's ok for me to remove the check. I
added it just because this __nullable suffix only serves tp_btf now.
And thanks for your nice suggestions. I'll fix them in the next version.
Also, thanks for the information about retsnoop. Our solutions seem to
be similar, and I'll look into it further. Honestly, it takes me some
time to get argument names from tp_btf, and I cannot find a better
solution but to use btp->bpf_func with kallsyms...
--
Philo
Powered by blists - more mailing lists