From: Eduard Zingerman <eddyz87@gmail.com>
To: Hao Sun <sunhao.th@gmail.com>, bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly
Date: Thu, 18 Jan 2024 16:38:38 +0200 [thread overview]
Message-ID: <6db75915cae66ab64921c2a8aab2f1653a22ec97.camel@gmail.com> (raw)
In-Reply-To: <20240117094012.36798-1-sunhao.th@gmail.com>
On Wed, 2024-01-17 at 10:40 +0100, Hao Sun wrote:
> Current checking rules are structured to disallow alu on particular ptr
> types explicitly, so default cases are allowed implicitly. This may lead
> to newly added ptr types being allowed unexpectedly. So restruture it to
> allow alu explicitly. The tradeoff is mainly a bit more cases added in
> the switch. The following table from Eduard summarizes the rules:
>
> | Pointer type | Arithmetics allowed |
> |---------------------+---------------------|
> | PTR_TO_CTX | yes |
> | CONST_PTR_TO_MAP | conditionally |
> | PTR_TO_MAP_VALUE | yes |
> | PTR_TO_MAP_KEY | yes |
> | PTR_TO_STACK | yes |
> | PTR_TO_PACKET_META | yes |
> | PTR_TO_PACKET | yes |
> | PTR_TO_PACKET_END | no |
> | PTR_TO_FLOW_KEYS | conditionally |
> | PTR_TO_SOCKET | no |
> | PTR_TO_SOCK_COMMON | no |
> | PTR_TO_TCP_SOCK | no |
> | PTR_TO_TP_BUFFER | yes |
> | PTR_TO_XDP_SOCK | no |
> | PTR_TO_BTF_ID | yes |
> | PTR_TO_MEM | yes |
> | PTR_TO_BUF | yes |
> | PTR_TO_FUNC | yes |
> | CONST_PTR_TO_DYNPTR | yes |
>
> The refactored rules are equivalent to the original one. Note that
> PTR_TO_FUNC and CONST_PTR_TO_DYNPTR are not reject here because: (1)
> check_mem_access() rejects load/store on those ptrs, and those ptrs
> with offset passing to calls are rejected check_func_arg_reg_off();
> (2) someone may rely on the verifier not rejecting programs earily.
>
> Signed-off-by: Hao Sun <sunhao.th@gmail.com>
> ---
Tried this on top of "Reject variable offset alu on PTR_TO_FLOW_KEYS",
all seems to be ok.
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
next prev parent reply other threads:[~2024-01-18 14:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 9:40 [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly Hao Sun
2024-01-17 9:42 ` Hao Sun
2024-01-18 14:38 ` Eduard Zingerman [this message]
2024-01-23 23:40 ` patchwork-bot+netdevbpf
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=6db75915cae66ab64921c2a8aab2f1653a22ec97.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=linux-kernel@vger.kernel.org \
--cc=sunhao.th@gmail.com \
/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).