New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpf: allow cgroup progs to export custom retval to userspace #2362
Conversation
Master branch: e63a023 |
Master branch: 5e22dd1 |
752100f
to
2016327
Compare
Master branch: 218d747 |
2016327
to
8ed681b
Compare
Master branch: ca796fe |
8ed681b
to
6fab159
Compare
Master branch: ca796fe |
6fab159
to
f254ae8
Compare
Master branch: 58d8a3f |
f254ae8
to
552d1d8
Compare
Master branch: a5bebc4 |
552d1d8
to
813ac93
Compare
Master branch: 2847993 |
813ac93
to
79fff97
Compare
Master branch: 2847993 |
79fff97
to
3876f49
Compare
Master branch: 7218c28 |
3876f49
to
600dd69
Compare
Master branch: 51a33c6 |
600dd69
to
19f6c3b
Compare
Master branch: 5f60826 |
19f6c3b
to
174eb21
Compare
Master branch: 640a171 |
174eb21
to
bb5baa1
Compare
Master branch: 1372d34 |
bb5baa1
to
2571c53
Compare
Master branch: 775a64e |
2a89330
to
25f0710
Compare
Master branch: 775a64e |
25f0710
to
7a0fa46
Compare
Master branch: 775a64e |
7a0fa46
to
9d891b0
Compare
775a64e
to
86c7eca
Compare
Master branch: 86c7eca |
9d891b0
to
4800950
Compare
Master branch: 000daa0 |
4800950
to
3329b60
Compare
000daa0
to
71a3cdf
Compare
Master branch: 71a3cdf |
3329b60
to
2aabd3d
Compare
Master branch: 0e3a1c9 |
2aabd3d
to
56854eb
Compare
Right now BPF_PROG_RUN_ARRAY and related macros return 1 or 0 for whether the prog array allows or rejects whatever is being hooked. The caller of these macros then return -EPERM or continue processing based on thw macro's return value. Unforunately this is inflexible, since -EPERM is the only err that can be returned. This patch should be a no-op; it prepares for the next patch. The returning of the -EPERM is moved to inside the macros, so the outer functions are directly returning what the macros returned if they are non-zero. Signed-off-by: YiFei Zhu <zhuyifei@google.com> Reviewed-by: Stanislav Fomichev <sdf@google.com>
The retval value is moved to struct bpf_cg_run_ctx for ease of access in different prog types with different context structs layouts. The helper implementation (to be added in a later patch in the series) can simply perform a container_of from current->bpf_ctx to retrieve bpf_cg_run_ctx. Unfortunately, there is no easy way to access the current task_struct via the verifier BPF bytecode rewrite, aside from possibly calling a helper, so a pointer to current task is added to struct bpf_sockopt_kern so that the rewritten BPF bytecode can access struct bpf_cg_run_ctx with an indirection. For backward compatibility, if a getsockopt program rejects a syscall by returning 0, an -EPERM will be generated, by having the BPF_PROG_RUN_ARRAY_CG family macros automatically set the retval to -EPERM. Unlike prior to this patch, this -EPERM will be visible to ctx->retval for any other hooks down the line in the prog array. Additionally, the restriction that getsockopt filters can only set the retval to 0 is removed, considering that certain getsockopt implementations may return optlen. Filters are now able to set the value arbitrarily. Signed-off-by: YiFei Zhu <zhuyifei@google.com> Reviewed-by: Stanislav Fomichev <sdf@google.com>
…n value The helpers continue to use int for retval because all the hooks are int-returning rather than long-returning. The return value of bpf_set_retval is int for future-proofing, in case in the future there may be errors trying to set the retval. After the previous patch, if a program rejects a syscall by returning 0, an -EPERM will be generated no matter if the retval is already set to -err. This patch change it being forced only if retval is not -err. This is because we want to support, for example, invoking bpf_set_retval(-EINVAL) and return 0, and have the syscall return value be -EINVAL not -EPERM. This change is reflected in the sockopt_sk test which has been updated to assert the errno is EINVAL instead of the EPERM. The eBPF prog has to explicitly bpf_set_retval(-EPERM) if EPERM is wanted. I also removed the explicit mentions of EPERM in the comments in the prog. For BPF_PROG_CGROUP_INET_EGRESS_RUN_ARRAY, the prior behavior is that, if the return value is NET_XMIT_DROP, the packet is silently dropped. We preserve this behavior for backward compatibility reasons, so even if an errno is set, the errno does not return to caller. However, setting a non-err to retval cannot propagate so this is not allowed and we return a -EFAULT in that case. Signed-off-by: YiFei Zhu <zhuyifei@google.com> Reviewed-by: Stanislav Fomichev <sdf@google.com>
Master branch: e80f2a0 |
The tests checks how different ways of interacting with the helpers (getting retval, setting EUNATCH, EISCONN, and legacy reject returning 0 without setting retval), produce different results in both the setsockopt syscall and the retval returned by the helper. A few more tests verify the interaction between the retval of the helper and the retval in getsockopt context. Signed-off-by: YiFei Zhu <zhuyifei@google.com> Reviewed-by: Stanislav Fomichev <sdf@google.com>
56854eb
to
a7ff573
Compare
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=596347 expired. Closing PR. |
Pull request for series with
subject: bpf: allow cgroup progs to export custom retval to userspace
version: 3
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=602668