Skip to content

Handle "global and assumed valid" messages #66

Merged
jordalgo merged 2 commits intomasterfrom
global-func-calls
Aug 29, 2025
Merged

Handle "global and assumed valid" messages #66
jordalgo merged 2 commits intomasterfrom
global-func-calls

Conversation

@theihor
Copy link
Copy Markdown
Collaborator

@theihor theihor commented Aug 28, 2025

Verifier may emit a message indicating a global function call, which
is not verified inline, for example:

565: (85) call pc+234
Func#5 ('pick_any_bit') is global and assumed valid.

This is important for visualizer, because so far call pc+offset
pattern was handled exclusively as subprogram call.

A small challenge with this is that the overall design of bpfvv
expects line-by-line processing of the input log. And to handle cases
like this some backtracking (or lookahead) mechanism is necessary,
even though it is convenient to work with "lines" fundamentally.

Address this with the following changes:

  • introduce ParsedLineType.KNOWN_MESSAGE and KnownMessageInfo to
    recognize particular verifier messages
  • leave parser interface unchanged (parseLine)
  • split parsed lines processing in the analyzer into separate steps
    • parse lines individually
    • process known messages, potentially editing parsedLines
      array (this is backtracking essentially)
    • and then build bpfStates and cSourceMap

@theihor
Copy link
Copy Markdown
Collaborator Author

theihor commented Aug 28, 2025

Closes #64

@theihor theihor requested a review from jordalgo August 28, 2025 20:38
Verifier may emit a message indicating a global function call, which
is not verified inline, for example:

    565: (85) call pc+234
    Func#5 ('pick_any_bit') is global and assumed valid.

This is important for visualizer, because so far `call pc+offset`
pattern was handled exclusively as subprogram call.

A small challenge with this is that the overall design of bpfvv
expects line-by-line processing of the input log. And to handle cases
like this some backtracking (or lookahead) mechanism is necessary,
even though it is convenient to work with "lines" fundamentally.

Address this with the following changes:
* introduce ParsedLineType.KNOWN_MESSAGE and KnownMessageInfo to
  recognize particular verifier messages
* leave parser interface unchanged (parseLine)
* split parsed lines processing in the analyzer into separate steps
  * parse lines individually
  * process known messages, potentially editing parsedLines
    array (this is backtracking essentially)
  * and then build bpfStates and cSourceMap
Fix off-by-one bug in LogLineRaw component when computing indentation.

Before this fix, the following fragment would not be indented:

    586: (85) call pc+243
    ...
    830: frame1: R1_w=map_value(map=third_pa.bss,ks=4,vs=5044,off=128,smin=smin32=0,smax=umax=smax32=umax32=4416,var_off=(0x0; 0x1fc0)) R10=fp0
    ; static int pick_most_loaded_cpu(struct cpdom_ctx *cpdomc) { @ balance.bpf.inc:180
    830: (7b) *(u64 *)(r10 -32) = r1      ; frame1: R1_w=map_value(map=third_pa.bss,ks=4,vs=5044,off=128,smin=smin32=0,smax=umax=smax32=umax32=4416,var_off=(0x0; 0x1fc0)) R10=fp0 fp-32_w=map_value(map=third_pa.bss,ks=4,vs=5044,off=128,smin=smin32=0,smax=umax=smax32=umax32=4416,var_off=(0x0; 0x1fc0))
    831: (b4) w0 = -2                     ; frame1: R0_w=0xfffffffe
    ; if (!per_cpu_dsq) @ balance.bpf.inc:185
    832: (18) r1 = 0xffffc90001bdfc1a     ; frame1: R1_w=map_value(map=third_pa.rodata,ks=4,vs=17826,off=3098)
    834: (71) r1 = *(u8 *)(r1 +0)         ; frame1: R1_w=0
    835: (56) if w1 != 0x1 goto pc+78     ; frame1: R1_w=0
    ; } @ balance.bpf.inc:206
    914: (95) exit
@theihor theihor force-pushed the global-func-calls branch from 7ff8d3e to 54fb5e1 Compare August 28, 2025 23:21
@jordalgo jordalgo merged commit 50cef6c into master Aug 29, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants