[PATCH bpf-next v4 0/7] bpf: infer zext_dst based on static register liveness analysis

Min-gyu Kim reported a bug in 32-bit operations zero extension
handling [1]. The same issue was independently identified by
STAR Labs SG. The bug was introduced by the commit [2].
The tl;dr of the bug is that the verifier does not carry zero
extension marks across pruning points. The detailed mechanism is
described in patch #3.

Fix this by reworking zero extension logic to avoid main-path based
subreg_def tracking, and instead extend the live registers analysis to
track upper register halves' liveness.

As noted in the commit message for patch #3:

  There is one notable drop in precision: whenever a BPF subprogram is
  called, all 64 bits of parameter registers are presumed to be used.
  The assumption is that such a drop in precision would not inflict
  noticeable performance penalty.

Ilya, could you please help with testing this conjecture?
Min-gyu, could you please test the proposed fix against your
reproducer?

Side note:
Patch #1 is a small refactoring for disasm.c, as patch #3 adds a new
location where bpf_verbose_insn() is called and there as well I have
to wrangle with the newline added by the disasm code.

[1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/
[2] commit 107e16979905 ("bpf: disable and remove registers chain based liveness")

Changelog:
v1 -> v2:
- fixed BPF_JMP32 handling, these no longer for zero extension (sashiko)
- removed dead code in print_insn_for_graph() (bot+bpf-ci)
- reworked bpf_is_reg64() to drop dead code (sashiko, bot+bpf-ci)

v2 -> v3:
- fix for proper s390x calling convention all call parameters are now
  zero extended if necessary (sashiko)
- fix for PTR_TO_ARENA alu operations to set zext_dst when needs_zext
  is set, in order for such operations to be zero extended (sashiko)
- updated bpf_is_reg64() to handle BPR_PROBE_MEM{,32} loads in order
  to avoid a false positive from sashiko.

v3 -> v4:
- fix to properly handle address space cast instructions for
  arena maps with BPF_F_NO_USER_CONV (sashiko):
  - extracted is_addr_space_cast32() utility function,
    for use in bpf_do_misc_fixups() and bpf_is_reg64();
  - made bpf_is_reg64() aware of such address space casts.
- added a note about report from STAR Labs SG.

v1: https://lore.kernel.org/bpf/[email protected]/T/
v2: https://lore.kernel.org/bpf/[email protected]/T/
v3: https://lore.kernel.org/bpf/[email protected]/T/

---
Eduard Zingerman (7):
      bpf: do not print a newline after disassembly in bpf_verbose_insn()
      bpf: extract is_addr_space_cast32() utility function
      bpf: move bpf_is_reg64() to fixups.c
      bpf: track upper 32-bit register halves' liveness in compute_live_registers()
      bpf: infer zext_dst based on static register liveness analysis
      bpf: simplify the bpf_is_reg64()
      selftests/bpf: verify zext_dst annotations for various instructions

 include/linux/bpf_verifier.h                      |   7 +-
 kernel/bpf/backtrack.c                            |   1 +
 kernel/bpf/disasm.c                               |  68 ++--
 kernel/bpf/fixups.c                               | 100 ++++--
 kernel/bpf/liveness.c                             | 109 ++++--
 kernel/bpf/verifier.c                             | 204 +----------
 tools/bpf/bpftool/xlated_dumper.c                 |  19 +-
 tools/testing/selftests/bpf/disasm_helpers.c      |   3 +-
 tools/testing/selftests/bpf/prog_tests/verifier.c |   2 +
 tools/testing/selftests/bpf/progs/verifier_zext.c | 392 ++++++++++++++++++++++
 10 files changed, 596 insertions(+), 309 deletions(-)
---
base-commit: 41c129fdc28b6414d259da72679567c5e72a55dd
change-id: 20260731-static-zext-938cd128273c