> selftests/bpf: Cover the low-32 link for zero-extending movs TL;DR: - Selftest comment calls the mixed-kind no-sync case unsound, but the program is safe; it is only lost precision - Commit message says "Twelve" programs, but there are thirteen
> selftests/bpf: Cover the low-32 link for zero-extending movs > > Twelve programs, one per decision the previous patch makes: > > - zext_mov_narrow_src: narrowing the source reaches the destination > - zext_sync_makes_member_const: and over all 64 bits, since the member > is the zero-extension > - zext_narrow_dst_keeps_base: the reverse must not happen > - zext_u32_src_is_full_link: a provably-u32 source still propagates > - zext_self_mov_no_link: a self-mov mints no id > - zext_chain_drops_link: a second 32-bit mov drops the link > - zext_no_sync_between_mixed_kinds: differing kinds do not reach each > other, in either direction > - zext_no_sync_from_subreg_base: nor does a member reach a base whose > high half it knows nothing about > - zext_sync_between_two_subregs: two low-32 links on one base do > - zext_unlinked_path_stays_reachable: one unlinked path keeps the > guarded div reachable > - zext_mov_breaks_linked_src: forming the link drops the source's own > - zext_sync_keeps_narrower_member: narrowing the base does not widen a > member that already proved itself tighter > - zext_contradiction_keeps_range_sane: a contradiction leaves no empty > range behind, under BPF_F_TEST_REG_INVARIANTS so the violation is a > load failure rather than something only dmesg sees > > Written in asm so the bytecode is the same whichever compiler built the > suite. > > Signed-off-by: Vineet Gupta <[email protected]> The changelog says "Twelve programs", but the list below it has thirteen bullets, and the patch adds thirteen programs: zext_mov_narrow_src, zext_sync_makes_member_const, zext_contradiction_keeps_range_sane, zext_narrow_dst_keeps_base, zext_u32_src_is_full_link, zext_self_mov_no_link, zext_chain_drops_link, zext_no_sync_between_mixed_kinds, zext_no_sync_from_subreg_base, zext_sync_between_two_subregs, zext_sync_keeps_narrower_member, zext_unlinked_path_stays_reachable and zext_mov_breaks_linked_src. The count looks like it was not updated when zext_contradiction_keeps_range_sane was added. It is the last bullet, but the third program in the file. Should "Twelve" be "Thirteen"? > diff --git a/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c > b/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c > --- a/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c > +++ b/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c [ ... ] > @@ -710,4 +710,352 @@ l_exit_%=: > \ [ ... ] > +/* > + * Two members of one id set carrying different link kinds do not propagate > + * to each other: r7 is (u32)base and r8 is base + 3, and the deltas were > + * added at different ALU widths, so narrowing r8 says nothing about r7. > + * sync_linked_regs() declines the pair on the kinds before the deltas are > + * ever consulted. Note neither register is the base -- that is r6. > + */ > +SEC("socket") > +__failure __msg("div by zero") > +__naked void zext_no_sync_between_mixed_kinds(void) > +{ > + asm volatile (" \ > + call %[bpf_get_prandom_u32]; \ > + r6 = r0; \ > + w7 = w6; /* forms the link */ \ > + r8 = r6; \ > + r8 += 3; /* r8 is BPF_REG_LINK_FULL, r7 is > BPF_REG_LINK_ZEXT */ \ > + if r8 != 3 goto 1f; /* must not propagate to r7 */ \ > + if w7 == 0 goto 1f; \ > + r0 /= 0; \ > +1: \ > + r0 = 0; \ > + exit; \ > +" : > + : __imm(bpf_get_prandom_u32) > + : __clobber_all); > +} ^^^^ This isn't a bug, but is the comment accurate for this direction? It says narrowing r8 "says nothing about r7", and the asm comment says the narrowing "must not propagate to r7". r8 is a BPF_REG_LINK_FULL member, so r8 == r6 + 3 over all 64 bits. That relation inverts exactly, so knowing r8 pins the base, and r7 == (u32)(r8 - 3) follows. In this program the fall-through of "if r8 != 3 goto 1f" forces r6 == 0, so r7 == 0, "if w7 == 0 goto 1f" is always taken, and "r0 /= 0" cannot be reached at runtime. The program is safe. The verifier rejects it only because sync_linked_regs() skips every pair with differing kinds: if (reg->link_kind && known_reg->link_kind && reg->link_kind != known_reg->link_kind) continue; That check exists for the other direction, a ZEXT known_reg against a FULL member (scalars_alu32_alu64_cross_type), where the 32-bit wrap really does break the relation. If the differencing arm ran for known=r8 (FULL, delta 3) and reg=r7 (ZEXT, delta 0), it would compute r8 + (0 - 3) and then zext_32_to_64(), which gives exactly (u32)(r8 - 3). That is sound. So this test pins a deliberate loss of precision, not a soundness requirement, but the comment presents it as unsound. The text is unchanged at the tip of the series. Someone who later makes the verifier propagate FULL -> ZEXT will see this test fail, and the comment will suggest the improvement is wrong. zext_chain_drops_link and zext_mov_breaks_linked_src also reject runtime-safe programs, but their comments say the link is dropped by rule. Could this one be worded the same way, for example "sync_linked_regs() declines mixed kinds even where, as here, the relation would hold"? --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/39458500836
