diff options
| author | Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com> | 2026-09-03 15:51:30 +0200 |
|---|---|---|
| committer | Alexei Starovoitov <ast@kernel.org> | 2026-09-04 09:54:18 -0700 |
| commit | d02bfbc49c8ef978eac5f39a2de67281b8e00edb (patch) | |
| tree | 3d311ac8b05d49d705920a71ab35f8b5a654bb78 /tools/lib/python | |
| parent | 7bf591f26545f5776a4e42d08c06fd94469766dd (diff) | |
| download | linux-next-d02bfbc49c8ef978eac5f39a2de67281b8e00edb.tar.gz linux-next-d02bfbc49c8ef978eac5f39a2de67281b8e00edb.zip | |
bpf: mark instructions accessing program stack
In order to prepare to emit KASAN checks in JITed programs, JIT
compilers need to be aware about whether some load/store instructions
are targeting the bpf program stack, as those should not be monitored
(we already have guard pages for that, and it is difficult anyway to
correctly monitor any kind of data passed on stack).
To support this need, make the BPF verifier mark the instructions
depending on whether they could access or not memory other than stack.
As different states in the verifier could lead to different memory types
for the same access, just marking an instruction as accessing stack only
is not enough (it could be some other memory type in another verifier
state), so the algorithm rather sets by default any load/store
instruction as stack only, and if _any_ state leads to any memory access
type other than PTR_TO_STACK, it overrides this setting. It also takes
care about shifting back the instruction marking in adjust_insn_aux_data
if the verifier patches instructions. However, if the verifier generates
new BPF_ST/BPF_STX/BPF_LDX while patching some instructions, those new
ones are systematically marked as non-stack-accessing: this may
over-instrument a few memory accessing instructions, but it allows
making sure that we will not miss accidentally any.
Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
Link: https://lore.kernel.org/r/20260903-kasan-v9-1-2407fe99255a@bootlin.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions
