Re: [PATCH bpf-next v3 05/12] selftests/bpf: Cover the low-32 link for zero-extending movs

[Vineet Gupta <vineet.gupta@linux.dev>]

On 10/20/26 9:53 AM, bot+bpf-ci@kernel.org wrote:
>> 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 <vineet.gupta@linux.dev>
> 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"?

Yes there was a last minute test update and this missed the update.

>> 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"?

Yes this is correct as well, I'll update the comments.

Thx,
-Vineet

>
>
> ---
> 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