From: Eduard Zingerman <eddyz87@gmail.com>
To: Daniel Xu <dxu@dxuuu.xyz>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
andrii@kernel.org, ast@kernel.org, shuah@kernel.org,
daniel@iogearbox.net, john.fastabend@gmail.com,
martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev,
kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
jolsa@kernel.org, mykolal@fb.com, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 4/5] bpf: verifier: Support eliding map lookup nullness
Date: Thu, 19 Dec 2024 16:43:08 -0800 [thread overview]
Message-ID: <d0b5e424445f498fdedca04fd4b0f138fbb6ae36.camel@gmail.com> (raw)
In-Reply-To: <f7taicw6c3f3yae4d6lrdagv26jiuihumklo4tkmqduvauargi@ld4bcmsbbiqn>
On Thu, 2024-12-19 at 17:40 -0700, Daniel Xu wrote:
[...]
> > Ok, thinking a bit more, the best test I can come up with is:
> >
> > u8 vals[8];
> > vals[0] = 0;
> > ...
> > vals[6] = 0;
> > vals[7] = 0xf;
> > p = bpf_map_lookup_elem(... vals ...);
> > *p = 42;
> >
> > For LE vals as u32 should be 0x0f;
> > For BE vals as u32 should be 0xf000_0000.
> > Hence, it is not safe to remove null check for this program.
> > What would verifier think about the value of such key?
> > As far as I understand, there would be stack zero for for vals[0-6]
> > and u8 stack spill for vals[7].
>
> Right. By checking that spill size is same as key size, we stay endian
> neutral, as constant values are tracked in native endianness.
>
> However, if we were to start interpreting combinations of STACK_ZERO,
> STACK_MISC, and STACK_SPILL, the verifier would have to be endian aware
> (IIUC). Which makes it a somewhat interesting problem but also requires
> some thought to correctly handle the state space.
Right.
> > You were going to add a check for the spill size, which should help here.
> > So, a negative test like above that checks that verifier complains
> > that 'p' should be checked for nullness first?
> >
> > If anyone has better test in mind, please speak-up.
>
> I think this case reduces down to a spill_size != key_size test. As long
> as the sizes match, we don't have to worry about endianness.
Agree.
next prev parent reply other threads:[~2024-12-20 0:43 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-12 23:22 [PATCH bpf-next v5 0/5] Support eliding map lookup nullness Daniel Xu
2024-12-12 23:22 ` [PATCH bpf-next v5 1/5] bpf: verifier: Add missing newline on verbose() call Daniel Xu
2024-12-12 23:22 ` [PATCH bpf-next v5 2/5] bpf: tcp: Mark bpf_load_hdr_opt() arg2 as read-write Daniel Xu
2024-12-16 18:18 ` Martin KaFai Lau
2024-12-12 23:22 ` [PATCH bpf-next v5 3/5] bpf: verifier: Refactor helper access type tracking Daniel Xu
2024-12-13 4:04 ` Eduard Zingerman
2024-12-13 20:02 ` Daniel Xu
2024-12-12 23:22 ` [PATCH bpf-next v5 4/5] bpf: verifier: Support eliding map lookup nullness Daniel Xu
2024-12-13 4:04 ` Eduard Zingerman
2024-12-13 20:57 ` Daniel Xu
2024-12-13 23:02 ` Andrii Nakryiko
2024-12-14 2:44 ` Daniel Xu
2024-12-14 3:13 ` Eduard Zingerman
2024-12-16 23:24 ` Andrii Nakryiko
2024-12-19 0:09 ` Daniel Xu
2024-12-19 21:41 ` Daniel Xu
2024-12-20 0:04 ` Eduard Zingerman
2024-12-20 0:40 ` Daniel Xu
2024-12-20 0:43 ` Eduard Zingerman [this message]
2024-12-20 0:49 ` Alexei Starovoitov
2024-12-20 4:00 ` Daniel Xu
2024-12-13 23:10 ` Kumar Kartikeya Dwivedi
2024-12-13 23:14 ` Eduard Zingerman
2024-12-13 23:18 ` Eduard Zingerman
2024-12-12 23:22 ` [PATCH bpf-next v5 5/5] bpf: selftests: verifier: Add nullness elision tests Daniel Xu
2024-12-14 6:17 ` Eduard Zingerman
2024-12-18 1:57 ` Daniel Xu
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=d0b5e424445f498fdedca04fd4b0f138fbb6ae36.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dxu@dxuuu.xyz \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.