-
Notifications
You must be signed in to change notification settings - Fork 5
bpf: properly verify tail call behavior #6390
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: properly verify tail call behavior #6390
Conversation
|
Upstream branch: 7dc211c |
|
Upstream branch: 7dc211c |
75a9521 to
c5f4f9d
Compare
|
Upstream branch: 7dc211c |
c5f4f9d to
bcd9e76
Compare
|
Upstream branch: 7dc211c |
bcd9e76 to
e71d838
Compare
c8a7e22 to
c919396
Compare
A successful ebpf tail call does not return to the caller, but to the caller-of-the-caller, often just finishing the ebpf program altogether. Any restrictions that the verifier needs to take into account - notably the fact that the tail call might have modified packet pointers - are to be checked on the caller-of-the-caller. Checking it on the caller made the verifier refuse perfectly fine programs that would use the packet pointers after a tail call, which is no problem as this code is only executed if the tail call was unsuccessful, i.e. nothing happened. This patch simulates the behavior of a tail call in the verifier. A conditional jump to the code after the tail call is added for the case of an unsucessful tail call, and a return to the caller is simulated for a successful tail call. For the successful case we assume that the tail call returns an int, as tail calls are currently only allowed in functions that return and int. We always assume that the tail call modified the packet pointers, as we do not know what the tail call did. For the unsuccessful case we know nothing happened, so we do not need to add new constraints. This approach also allows to check other problems that may occur with tail calls, namely we are now able to check that precision is properly propagated into subprograms using tail calls, as well as checking the live slots in such a subprogram. Fixes: 1a4607f ("bpf: consider that tail calls invalidate packet pointers") Link: https://lore.kernel.org/bpf/[email protected]/ Signed-off-by: Martin Teichmann <[email protected]> Acked-by: Eduard Zingerman <[email protected]>
Three tests are added: - invalidate_pkt_pointers_by_tail_call checks that one can use the packet pointer after a tail call. This was originally possible and also poses not problems, but was made impossible by 1a4607f. - invalidate_pkt_pointers_by_static_tail_call tests a corner case found by Eduard Zingerman during the discussion of the original fix, which was broken in that fix. - subprog_result_tail_call tests that precision propagation works correctly across tail calls. This did not work before. Signed-off-by: Martin Teichmann <[email protected]> Acked-by: Eduard Zingerman <[email protected]>
This updates bpf_insn_successors() reflecting that control flow might jump over the instructions between tail call and function exit, verifier might assume that some writes to parent stack always happen, which is not the case. Acked-by: Eduard Zingerman <[email protected]>
A new test is added: caller_stack_write_tail_call tests that the live stack is correctly tracked for a tail call. Acked-by: Eduard Zingerman <[email protected]>
|
Upstream branch: ec12ab2 |
e71d838 to
1b28125
Compare
c919396 to
73c6b0b
Compare
|
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=1024869 expired. Closing PR. |
Pull request for series with
subject: bpf: properly verify tail call behavior
version: 5
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1024869