From: Eduard Zingerman <eddyz87@gmail.com>
To: Shung-Hsi Yu <shung-hsi.yu@suse.com>, bpf@vger.kernel.org
Cc: "Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andriin@fb.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
"John Fastabend" <john.fastabend@gmail.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Song Liu" <song@kernel.org>,
"Yonghong Song" <yonghong.song@linux.dev>,
"KP Singh" <kpsingh@kernel.org>,
"Stanislav Fomichev" <sdf@google.com>,
"Hao Luo" <haoluo@google.com>, "Jiri Olsa" <jolsa@kernel.org>,
stable@vger.kernel.org, "Mohamed Mahmoud" <mmahmoud@redhat.com>,
"Tao Lyu" <tao.lyu@epfl.ch>
Subject: Re: [RFC bpf 1/2] bpf: Fix precision tracking for BPF_ALU | BPF_TO_BE | BPF_END
Date: Mon, 30 Oct 2023 16:28:19 +0200 [thread overview]
Message-ID: <0ee068765d5992f4907a6d3320d4c7c5b9e6e4ba.camel@gmail.com> (raw)
In-Reply-To: <20231030132145.20867-2-shung-hsi.yu@suse.com>
On Mon, 2023-10-30 at 21:21 +0800, Shung-Hsi Yu wrote:
> BPF_END and BPF_NEG has a different specification for the source bit in
> the opcode compared to other ALU/ALU64 instructions, and is either
> reserved or use to specify the byte swap endianness. In both cases the
> source bit does not encode source operand location, and src_reg is a
> reserved field.
>
> backtrack_insn() currently does not differentiate BPF_END and BPF_NEG
> from other ALU/ALU64 instructions, which leads to r0 being incorrectly
> marked as precise when processing BPF_ALU | BPF_TO_BE | BPF_END
> instructions. This commit teaches backtrack_insn() to correctly mark
> precision for such case.
>
> While precise tracking of BPF_NEG and other BPF_END instructions are
> correct and does not need fixing because their source bit are unset and
> thus treated as the BPF_K case, this commit opt to process all BPF_NEG
> and BPF_END instructions within the same if-clause so it better aligns
> with current convention used in the verifier (e.g. check_alu_op).
>
> Fixes: b5dc0163d8fd ("bpf: precise scalar_value tracking")
> Cc: stable@vger.kernel.org
> Reported-by: Mohamed Mahmoud <mmahmoud@redhat.com>
> Tested-by: Toke Høiland-Jørgensen <toke@redhat.com>
> Tested-by: Tao Lyu <tao.lyu@epfl.ch>
> Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> ---
> kernel/bpf/verifier.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 873ade146f3d..646dc49263fd 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -3426,7 +3426,12 @@ static int backtrack_insn(struct bpf_verifier_env *env, int idx, int subseq_idx,
> if (class == BPF_ALU || class == BPF_ALU64) {
> if (!bt_is_reg_set(bt, dreg))
> return 0;
> - if (opcode == BPF_MOV) {
> + if (opcode == BPF_END || opcode == BPF_NEG) {
> + /* sreg is reserved and unused
> + * dreg still need precision before this insn
> + */
> + return 0;
> + } else if (opcode == BPF_MOV) {
> if (BPF_SRC(insn->code) == BPF_X) {
> /* dreg = sreg or dreg = (s8, s16, s32)sreg
> * dreg needs precision after this insn
next prev parent reply other threads:[~2023-10-30 14:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-30 13:21 [RFC bpf 0/2] bpf: Fix precision tracking for BPF_ALU | BPF_TO_BE | BPF_END Shung-Hsi Yu
2023-10-30 13:21 ` [RFC bpf 1/2] " Shung-Hsi Yu
2023-10-30 14:28 ` Eduard Zingerman [this message]
2023-10-30 13:21 ` [RFC bpf 2/2] selftests/bpf: precision tracking test " Shung-Hsi Yu
2023-10-30 14:36 ` Eduard Zingerman
2023-10-30 17:17 ` Alexei Starovoitov
2023-10-31 5:22 ` Shung-Hsi Yu
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=0ee068765d5992f4907a6d3320d4c7c5b9e6e4ba.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mmahmoud@redhat.com \
--cc=sdf@google.com \
--cc=shung-hsi.yu@suse.com \
--cc=song@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tao.lyu@epfl.ch \
--cc=toke@redhat.com \
--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.