You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BPF allows passing stack pointers to a subprogram, which then can do
load/store operations on such pointers.
In the verification log, such pointers are referred to with the
following notation: `fp[<frame>]<offset>`, for example `fp[1]-64`.
In particular, bpf_loop [1] helper accepts a callback and pointer to
context, which must be a stack pointer. And so the verifier log trace
for bpf_loop looks like a helper call, followed by instruction stream
of the callback function (in the new frame), but with the reference to
the context in one of the registers.
These changes implement support for value references and dependency
tracking of stack slots at arbitrary depth, as well as UI changes to
display all stack frames (and not only the current one).
This is achieved by introduction of `BpfMemSlotMap` type. It's
essentially a map with string keys, except that it maintains
currentFrame value to be able to correctly identify the frame of
references like `fp-64` where frame is not specified.
`BpfState` is factored out into a class and the `values` and
`lastKnownWrites` maps of `BpfState` thus become `BpfMemSlotMap`s,
allowing to not modify the logic of how they are built and maintained
for the most part.
Implement carrying over of stack values from parent frame to inner
frame and back (on exit), so that inter-frame stack slot dependencies
can be tracked.
[1] https://docs.ebpf.io/linux/helper-function/bpf_loop/
0 commit comments