-
Notifications
You must be signed in to change notification settings - Fork 5
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 control flow graph and precision backtrack fixes #647
Conversation
Upstream branch: b4e59c1 |
d955544
to
dc3526c
Compare
Upstream branch: b4e59c1 |
36d1d6f
to
b7ad91e
Compare
902178a
to
bc1b833
Compare
Upstream branch: 3815f89 |
b7ad91e
to
0afcd99
Compare
0fbe9f3
to
b0d20d2
Compare
Upstream branch: 6f101db |
0afcd99
to
0cf98d5
Compare
1e02037
to
a98cbca
Compare
Upstream branch: e80742d |
0cf98d5
to
64221bf
Compare
a98cbca
to
b7b6ef0
Compare
Upstream branch: e80742d |
64221bf
to
9a4beb0
Compare
b7b6ef0
to
293e027
Compare
Upstream branch: e80742d |
9a4beb0
to
4225fd7
Compare
293e027
to
260b428
Compare
Upstream branch: e80742d |
4225fd7
to
c2d10dc
Compare
260b428
to
08949e6
Compare
ldimm64 instructions are 16-byte long, and so have to be handled appropriately in check_cfg(), just like the rest of BPF verifier does. This has implications in three places: - when determining next instruction for non-jump instructions; - when determining next instruction for callback address ldimm64 instructions (in visit_func_call_insn()); - when checking for unreachable instructions, where second half of ldimm64 is expected to be unreachable; We take this also as an opportunity to report jump into the middle of ldimm64. And adjust few test_verifier tests accordingly. Acked-by: Eduard Zingerman <[email protected]> Reported-by: Hao Sun <[email protected]> Fixes: 475fb78 ("bpf: verifier (add branch/goto checks)") Signed-off-by: Andrii Nakryiko <[email protected]>
Fix an edge case in __mark_chain_precision() which prematurely stops backtracking instructions in a state if it happens that state's first and last instruction indexes are the same. This situations doesn't necessarily mean that there were no instructions simulated in a state, but rather that we starting from the instruction, jumped around a bit, and then ended up at the same instruction before checkpointing or marking precision. To distinguish between these two possible situations, we need to consult jump history. If it's empty or contain a single record "bridging" parent state and first instruction of processed state, then we indeed backtracked all instructions in this state. But if history is not empty, we are definitely not done yet. Move this logic inside get_prev_insn_idx() to contain it more nicely. Use -ENOENT return code to denote "we are out of instructions" situation. This bug was exposed by verifier_loop1.c's bounded_recursion subtest, once the next fix in this patch set is applied. Acked-by: Eduard Zingerman <[email protected]> Fixes: b5dc016 ("bpf: precise scalar_value tracking") Signed-off-by: Andrii Nakryiko <[email protected]>
Add a dedicated selftests to try to set up conditions to have a state with same first and last instruction index, but it actually is a loop 3->4->1->2->3. This confuses mark_chain_precision() if verifier doesn't take into account jump history. Signed-off-by: Andrii Nakryiko <[email protected]>
Upstream branch: 155addf |
c2d10dc
to
bea5c92
Compare
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=800079 irrelevant now. Closing PR. |
Pull request for series with
subject: BPF control flow graph and precision backtrack fixes
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=799796