[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACkBjsa+gOh0pFPctnigXs9ugW06efCqZ+qn+dTcyRJbf6z-MQ@mail.gmail.com>
Date: Thu, 22 Dec 2022 10:30:19 +0800
From: Hao Sun <sunhao.th@...il.com>
To: Martin KaFai Lau <martin.lau@...ux.dev>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
John Fastabend <john.fastabend@...il.com>,
Andrii Nakryiko <andrii@...nel.org>,
Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...gle.com>,
Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
David Miller <davem@...emloft.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next v2 2/2] selftests/bpf: check null propagation
only neither reg is PTR_TO_BTF_ID
Martin KaFai Lau <martin.lau@...ux.dev> 于2022年12月22日周四 05:21写道:
>
> On 12/21/22 5:46 AM, Hao Sun wrote:
> > Hi,
> >
> > I’ve tried something like the bellow, but soon realized that this
> > won’t work because once compiler figures out `inner_map` equals
> > to `val`, it can choose either reg to write into in the following
> > path, meaning that this program can be rejected due to writing
> > into read-only PTR_TO_BTF_ID reg, and this makes the test useless.
>
> hmm... I read the above a few times but I still don't quite get it. In
> particular, '...can be rejected due to writing into read-only PTR_TO_BTF_ID
> reg...'. Where is it writing into a read-only PTR_TO_BTF_ID reg in the
> following bpf prog? Did I overlook something?
>
> >
> > Essentially, we want two regs, one points to PTR_TO_BTD_ID, one
> > points to MAP_VALUR_OR_NULL, then compare them and deref map val.
>
> If I read this request correctly, I guess the compiler has changed 'ret = *val'
> to 'ret = *inner_map'? Thus, the verifier did not reject because it deref a
> PTR_TO_BTF_ID?
>
Yes, and if we do "*val = 0", it's rejected due to writing to read-only
PTR_TO_BTF_ID reg.
> > It’s hard to implement this in C level because compilers decide
> > which reg to use but not us, maybe we can just drop this test.
>
> Have you tried inline assembly. Something like this (untested):
>
> asm volatile (
> "r8 = %[val];\n"
> "r9 = %[inner_map];\n"
> "if r8 != r9 goto +1;\n"
> "%[ret] = *(u64 *)(r8 +0);\n"
> :[ret] "+r"(ret)
> : [inner_map] "r"(inner_map), [val] "r"(val)
> :"r8", "r9");
>
This would work, didn't realize that I can inline BPF insns this way.
Thanks!
> Please attach the verifier output in the future. It will be easier to understand.
>
Will do the next time.
Powered by blists - more mailing lists