From: Eduard Zingerman <eddyz87@gmail.com>
To: Daniel Xu <dxu@dxuuu.xyz>,
andrii@kernel.org, ast@kernel.org, shuah@kernel.org,
daniel@iogearbox.net
Cc: martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, mykolal@fb.com,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v6 5/5] bpf: selftests: verifier: Add nullness elision tests
Date: Thu, 02 Jan 2025 19:16:39 -0800 [thread overview]
Message-ID: <cf0da119ef36fed757198a870952763a0cf48513.camel@gmail.com> (raw)
In-Reply-To: <478d188ecd9ac004ffae6fba969b71364adbab1a.1734667691.git.dxu@dxuuu.xyz>
On Thu, 2024-12-19 at 21:09 -0700, Daniel Xu wrote:
> Test that nullness elision works for common use cases. For example, we
> want to check that both constant scalar spills and STACK_ZERO functions.
> As well as when there's both const and non-const values of R2 leading up
> to a lookup. And obviously some bound checks.
>
> Particularly tricky are spills both smaller or larger than key size. For
> smaller, we need to ensure verifier doesn't let through a potential read
> into unchecked bytes. For larger, endianness comes into play, as the
> native endian value tracked in the verifier may not be the bytes the
> kernel would have read out of the key pointer. So check that we disallow
> both.
>
> Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> ---
Nit: a few cases are omitted from these tests:
1. a key is not a pointer to stack;
2. a key is not a constant pointer;
3. value on stack is not a spill;
4. precision mark for stack value;
I think (1) and (4) are worth testing.
For (4) I think matching log messages about marking stack slot
precise should be sufficient (register and slot index numbers are
not guaranteed since tests are written in C, but regular expressions
could be used in __msg using '{{' '}}' brackets, e.g.: '{{r[0-9]}}'.
An alternative would be to write a test case where precision mark
matters (a branch before map lookup with invalid key value used
in a branch that is verified second). Such test would have to
be written in inline assembly to guarantee code verification order.
This might be an overkill.
[...]
prev parent reply other threads:[~2025-01-03 3:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 4:09 [PATCH bpf-next v6 0/5] Support eliding map lookup nullness Daniel Xu
2024-12-20 4:09 ` [PATCH bpf-next v6 1/5] bpf: verifier: Add missing newline on verbose() call Daniel Xu
2024-12-20 4:09 ` [PATCH bpf-next v6 2/5] bpf: tcp: Mark bpf_load_hdr_opt() arg2 as read-write Daniel Xu
2024-12-20 4:09 ` [PATCH bpf-next v6 3/5] bpf: verifier: Refactor helper access type tracking Daniel Xu
2024-12-20 4:09 ` [PATCH bpf-next v6 4/5] bpf: verifier: Support eliding map lookup nullness Daniel Xu
2025-01-03 2:53 ` Eduard Zingerman
2025-01-09 23:30 ` Daniel Xu
2024-12-20 4:09 ` [PATCH bpf-next v6 5/5] bpf: selftests: verifier: Add nullness elision tests Daniel Xu
2025-01-03 3:16 ` Eduard Zingerman [this message]
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=cf0da119ef36fed757198a870952763a0cf48513.camel@gmail.com \
--to=eddyz87@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox