| Message ID | 20220207131459.504292-2-jakub@cloudflare.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | Split bpf_sk_lookup remote_port field | expand |
On 2/7/22 5:14 AM, Jakub Sitnicki wrote: > remote_port is another case of a BPF context field documented as a 32-bit > value in network byte order for which the BPF context access converter > generates a load of a zero-padded 16-bit integer in network byte order. > > First such case was dst_port in bpf_sock which got addressed in commit > 4421a582718a ("bpf: Make dst_port field in struct bpf_sock 16-bit wide"). > > Loading 4-bytes from the remote_port offset and converting the value with > bpf_ntohl() leads to surprising results, as the expected value is shifted > by 16 bits. > > Reduce the confusion by splitting the field in two - a 16-bit field holding > a big-endian integer, and a 16-bit zero-padding anonymous field that > follows it. > > Suggested-by: Alexei Starovoitov <ast@kernel.org> > Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> Acked-by: Yonghong Song <yhs@fb.com>
Hi Jakub,
I love your patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Jakub-Sitnicki/Split-bpf_sk_lookup-remote_port-field/20220207-215137
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: sparc-randconfig-s031-20220207 (https://download.01.org/0day-ci/archive/20220208/202202080631.n8UjqRXy-lkp@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 11.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-dirty
# https://github.com/0day-ci/linux/commit/b859a90e4c32a55e71d2731dd8dae96d7ad1defe
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Jakub-Sitnicki/Split-bpf_sk_lookup-remote_port-field/20220207-215137
git checkout b859a90e4c32a55e71d2731dd8dae96d7ad1defe
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=sparc SHELL=/bin/bash net/bpf/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> net/bpf/test_run.c:1149:55: sparse: sparse: restricted __be16 degrades to integer
vim +1149 net/bpf/test_run.c
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1111
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1112 int bpf_prog_test_run_sk_lookup(struct bpf_prog *prog, const union bpf_attr *kattr,
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1113 union bpf_attr __user *uattr)
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1114 {
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1115 struct bpf_test_timer t = { NO_PREEMPT };
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1116 struct bpf_prog_array *progs = NULL;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1117 struct bpf_sk_lookup_kern ctx = {};
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1118 u32 repeat = kattr->test.repeat;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1119 struct bpf_sk_lookup *user_ctx;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1120 u32 retval, duration;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1121 int ret = -EINVAL;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1122
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1123 if (prog->type != BPF_PROG_TYPE_SK_LOOKUP)
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1124 return -EINVAL;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1125
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1126 if (kattr->test.flags || kattr->test.cpu)
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1127 return -EINVAL;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1128
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1129 if (kattr->test.data_in || kattr->test.data_size_in || kattr->test.data_out ||
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1130 kattr->test.data_size_out)
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1131 return -EINVAL;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1132
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1133 if (!repeat)
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1134 repeat = 1;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1135
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1136 user_ctx = bpf_ctx_init(kattr, sizeof(*user_ctx));
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1137 if (IS_ERR(user_ctx))
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1138 return PTR_ERR(user_ctx);
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1139
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1140 if (!user_ctx)
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1141 return -EINVAL;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1142
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1143 if (user_ctx->sk)
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1144 goto out;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1145
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1146 if (!range_is_zero(user_ctx, offsetofend(typeof(*user_ctx), local_port), sizeof(*user_ctx)))
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1147 goto out;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1148
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 @1149 if (user_ctx->local_port > U16_MAX || user_ctx->remote_port > U16_MAX) {
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1150 ret = -ERANGE;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1151 goto out;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1152 }
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1153
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1154 ctx.family = (u16)user_ctx->family;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1155 ctx.protocol = (u16)user_ctx->protocol;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1156 ctx.dport = (u16)user_ctx->local_port;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1157 ctx.sport = (__force __be16)user_ctx->remote_port;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1158
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1159 switch (ctx.family) {
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1160 case AF_INET:
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1161 ctx.v4.daddr = (__force __be32)user_ctx->local_ip4;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1162 ctx.v4.saddr = (__force __be32)user_ctx->remote_ip4;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1163 break;
7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1164
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
On Mon, Feb 7, 2022 at 2:05 PM kernel test robot <lkp@intel.com> wrote: > 7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1148 > 7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 @1149 if (user_ctx->local_port > U16_MAX || user_ctx->remote_port > U16_MAX) { Jakub, are you planning to respin and remove that check?
On Tue, Feb 08, 2022 at 08:28 PM CET, Alexei Starovoitov wrote: > On Mon, Feb 7, 2022 at 2:05 PM kernel test robot <lkp@intel.com> wrote: >> 7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1148 >> 7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 @1149 if (user_ctx->local_port > U16_MAX || user_ctx->remote_port > U16_MAX) { > > Jakub, > are you planning to respin and remove that check? Yes, certainly. Just didn't get to it today. Can either respin the series or send a follow-up. Whatever works.
On Tue, Feb 8, 2022 at 12:42 PM Jakub Sitnicki <jakub@cloudflare.com> wrote: > > On Tue, Feb 08, 2022 at 08:28 PM CET, Alexei Starovoitov wrote: > > On Mon, Feb 7, 2022 at 2:05 PM kernel test robot <lkp@intel.com> wrote: > >> 7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 1148 > >> 7c32e8f8bc33a5f Lorenz Bauer 2021-03-03 @1149 if (user_ctx->local_port > U16_MAX || user_ctx->remote_port > U16_MAX) { > > > > Jakub, > > are you planning to respin and remove that check? > > Yes, certainly. Just didn't get to it today. > > Can either respin the series or send a follow-up. Whatever works. I think respin is better.
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index a7f0ddedac1f..afe3d0d7f5f2 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -6453,7 +6453,8 @@ struct bpf_sk_lookup { __u32 protocol; /* IP protocol (IPPROTO_TCP, IPPROTO_UDP) */ __u32 remote_ip4; /* Network byte order */ __u32 remote_ip6[4]; /* Network byte order */ - __u32 remote_port; /* Network byte order */ + __be16 remote_port; /* Network byte order */ + __u16 :16; /* Zero padding */ __u32 local_ip4; /* Network byte order */ __u32 local_ip6[4]; /* Network byte order */ __u32 local_port; /* Host byte order */ diff --git a/net/core/filter.c b/net/core/filter.c index 99a05199a806..83f06d3b2c52 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -10843,7 +10843,8 @@ static bool sk_lookup_is_valid_access(int off, int size, case bpf_ctx_range(struct bpf_sk_lookup, local_ip4): case bpf_ctx_range_till(struct bpf_sk_lookup, remote_ip6[0], remote_ip6[3]): case bpf_ctx_range_till(struct bpf_sk_lookup, local_ip6[0], local_ip6[3]): - case bpf_ctx_range(struct bpf_sk_lookup, remote_port): + case offsetof(struct bpf_sk_lookup, remote_port) ... + offsetof(struct bpf_sk_lookup, local_ip4) - 1: case bpf_ctx_range(struct bpf_sk_lookup, local_port): case bpf_ctx_range(struct bpf_sk_lookup, ingress_ifindex): bpf_ctx_record_field_size(info, sizeof(__u32));
remote_port is another case of a BPF context field documented as a 32-bit value in network byte order for which the BPF context access converter generates a load of a zero-padded 16-bit integer in network byte order. First such case was dst_port in bpf_sock which got addressed in commit 4421a582718a ("bpf: Make dst_port field in struct bpf_sock 16-bit wide"). Loading 4-bytes from the remote_port offset and converting the value with bpf_ntohl() leads to surprising results, as the expected value is shifted by 16 bits. Reduce the confusion by splitting the field in two - a 16-bit field holding a big-endian integer, and a 16-bit zero-padding anonymous field that follows it. Suggested-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> --- include/uapi/linux/bpf.h | 3 ++- net/core/filter.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)