From: Ilya Leoshkevich <iii@linux.ibm.com>
To: Jakub Sitnicki <jakub@cloudflare.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Ilya Leoshkevich <iii@linux.ibm.com>
Subject: [PATCH RFC bpf-next 1/3] bpf: Fix certain narrow loads with offsets
Date: Tue, 22 Feb 2022 19:25:57 +0100 [thread overview]
Message-ID: <20220222182559.2865596-2-iii@linux.ibm.com> (raw)
In-Reply-To: <20220222182559.2865596-1-iii@linux.ibm.com>
Verifier treats bpf_sk_lookup.remote_port as a 32-bit field for
backward compatibility, regardless of what the uapi headers say.
This field is mapped onto the 16-bit bpf_sk_lookup_kern.sport field.
Therefore, accessing the most significant 16 bits of
bpf_sk_lookup.remote_port must produce 0, which is currently not
the case.
The problem is that narrow loads with offset - commit 46f53a65d2de
("bpf: Allow narrow loads with offset > 0"), don't play nicely with
the masking optimization - commit 239946314e57 ("bpf: possibly avoid
extra masking for narrower load in verifier"). In particular, when we
suppress extra masking, we suppress shifting as well, which is not
correct.
Fix by moving the masking suppression check to BPF_AND generation.
Fixes: 46f53a65d2de ("bpf: Allow narrow loads with offset > 0")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
kernel/bpf/verifier.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d7473fee247c..195f2e9b5a47 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -12848,7 +12848,7 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
return -EINVAL;
}
- if (is_narrower_load && size < target_size) {
+ if (is_narrower_load) {
u8 shift = bpf_ctx_narrow_access_offset(
off, size, size_default) * 8;
if (shift && cnt + 1 >= ARRAY_SIZE(insn_buf)) {
@@ -12860,15 +12860,19 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
insn_buf[cnt++] = BPF_ALU32_IMM(BPF_RSH,
insn->dst_reg,
shift);
- insn_buf[cnt++] = BPF_ALU32_IMM(BPF_AND, insn->dst_reg,
- (1 << size * 8) - 1);
+ if (size < target_size)
+ insn_buf[cnt++] = BPF_ALU32_IMM(
+ BPF_AND, insn->dst_reg,
+ (1 << size * 8) - 1);
} else {
if (shift)
insn_buf[cnt++] = BPF_ALU64_IMM(BPF_RSH,
insn->dst_reg,
shift);
- insn_buf[cnt++] = BPF_ALU64_IMM(BPF_AND, insn->dst_reg,
- (1ULL << size * 8) - 1);
+ if (size < target_size)
+ insn_buf[cnt++] = BPF_ALU64_IMM(
+ BPF_AND, insn->dst_reg,
+ (1ULL << size * 8) - 1);
}
}
--
2.34.1
next prev parent reply other threads:[~2022-02-22 18:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-22 18:25 [PATCH RFC bpf-next 0/3] bpf_sk_lookup.remote_port fixes Ilya Leoshkevich
2022-02-22 18:25 ` Ilya Leoshkevich [this message]
2022-03-08 15:01 ` [PATCH RFC bpf-next 1/3] bpf: Fix certain narrow loads with offsets Jakub Sitnicki
2022-03-08 23:58 ` Ilya Leoshkevich
2022-03-09 8:36 ` Jakub Sitnicki
2022-03-09 12:34 ` Ilya Leoshkevich
2022-03-10 22:57 ` Jakub Sitnicki
2022-03-14 17:35 ` Jakub Sitnicki
2022-03-14 18:25 ` Ilya Leoshkevich
2022-03-14 20:57 ` Jakub Sitnicki
2022-02-22 18:25 ` [PATCH RFC bpf-next 2/3] bpf: Fix bpf_sk_lookup.remote_port on big-endian Ilya Leoshkevich
2022-02-27 2:44 ` Alexei Starovoitov
2022-02-27 20:30 ` Jakub Sitnicki
2022-02-28 10:19 ` Ilya Leoshkevich
2022-02-28 13:26 ` Jakub Sitnicki
2022-03-01 0:39 ` Ilya Leoshkevich
2022-03-01 0:40 ` Ilya Leoshkevich
2022-02-22 18:25 ` [PATCH RFC bpf-next 3/3] selftests/bpf: Adapt bpf_sk_lookup.remote_port loads Ilya Leoshkevich
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=20220222182559.2865596-2-iii@linux.ibm.com \
--to=iii@linux.ibm.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jakub@cloudflare.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