From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: "Alexis Lothoré (eBPF Foundation)" <alexis.lothore@bootlin.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"John Fastabend" <john.fastabend@gmail.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Song Liu" <song@kernel.org>,
"Yonghong Song" <yonghong.song@linux.dev>,
"Jiri Olsa" <jolsa@kernel.org>,
"Thomas Gleixner" <tglx@kernel.org>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Shuah Khan" <shuah@kernel.org>, "Ingo Molnar" <mingo@redhat.com>,
"Andrey Konovalov" <andreyknvl@gmail.com>
Cc: ebpf@linuxfoundation.org,
Bastien Curutchet <bastien.curutchet@bootlin.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 01/10] bpf: propagate original instruction offset when patching program
Date: Tue, 14 Jul 2026 17:47:32 -0700 [thread overview]
Message-ID: <bbbcbae7-a819-4f86-b116-6d5e31973a0e@linux.dev> (raw)
In-Reply-To: <20260709-kasan-v5-1-1c64af8e4e1e@bootlin.com>
On 7/9/26 3:01 AM, Alexis Lothoré (eBPF Foundation) wrote:
> When the verifier patches an ebpf program with bpf_patch_insn_data, it
> then calls adjust_insn_aux_data to make sure that insn_aux_data takes
> into account the newly inserted patch. Some of the data offset is pretty
> straightforward to deduce, it is for example the case for
> indirect_target, as any patch affecting indirect calls will
> systematically move the original instruction to the end of the new
> patch.
I think an additional KASAN-specific argument to adjust_insn_aux_data()
is not a good idea. It's threaded through ~30 call sites, and it's
been error-prone too: you had to fix the offsets a few times already.
indirect_target needs no help from the callers, so it's not really the
same pattern. Similar for the other aux fields: seen is broadcast and
zext_dst is re-derived.
>
> In order to introduce KASAN support for eBPF JIT, we need to mark any
> load/store instruction that accesses non-stack memory, but updating this
> new marking after a patch is not as straightforward as for indirect
> calls: the original BPF_ST/BPF_STX/BPF_LDX can be at the beginning, at
> the end or somewhere in the middle of the new patch: we then need some
> additional info to properly update this marking.
I don't think we need to track the exact offset here.
It looks like .non_stack_access is set to is_mem_insn(insn + off) in
every single case *except* for when a stack access happens to be in
the middle of a patch.
Given that the cost of getting the flag "wrong" is an unnecessary
kasan check only for that case, I think it'll be cleaner to just
unconditionally do:
data[off].non_stack_access = is_mem_insn(insn + off);
in adjust_insn_aux_data()
And then the code change can be folded in patch #2
The only problem with this I can think of is that in reality *most*
stack accesses go trough that special case, which would defeat the
purpose of the .non_stack_access flag. This can be checked empirically
however.
Anything else I'm missing here?
>
> Add a new parameter to bpf_patch_insn_data and adjust_insn_aux_data to
> convey the info about the new location in the patch of the original
> instruction. This info does not always make sense depending on the
> generated patch (eg, some bpf helpers being inlined by the verifier, and
> so turned into multiple new instructions without any remaining BPF_CALL),
> the parameter can then be set to -1. It will be used in next patches to
> properly handle insn_aux_data adjustment for the new KASAN
> instrumentation
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> Changes in v5:
> - fix a few incorrect offset values
>
> Changes in v4:
> - define insn_off_in_patch inside convert_ctx_accesses main loop to
> avoid old value leakage
>
> Changes in v3:
> - new patch
> ---
> include/linux/filter.h | 10 +++--
> kernel/bpf/core.c | 2 +-
> kernel/bpf/fixups.c | 100 ++++++++++++++++++++++++++++++++-----------------
> 3 files changed, 74 insertions(+), 38 deletions(-)
>
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index 14acb2455746..1ebcd247ef4e 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -1210,13 +1210,17 @@ struct bpf_prog *bpf_patch_insn_single(struct bpf_prog *prog, u32 off,
>
> #ifdef CONFIG_BPF_SYSCALL
> struct bpf_prog *bpf_patch_insn_data(struct bpf_verifier_env *env, u32 off,
> - const struct bpf_insn *patch, u32 len);
> + const struct bpf_insn *patch, u32 len,
> + s32 insn_off_in_patch);
> struct bpf_insn_aux_data *bpf_dup_insn_aux_data(struct bpf_verifier_env *env);
> void bpf_restore_insn_aux_data(struct bpf_verifier_env *env,
> struct bpf_insn_aux_data *orig_insn_aux);
> #else
> -static inline struct bpf_prog *bpf_patch_insn_data(struct bpf_verifier_env *env, u32 off,
> - const struct bpf_insn *patch, u32 len)
> +static inline struct bpf_prog *bpf_patch_insn_data(struct bpf_verifier_env *env,
> + u32 off,
> + const struct bpf_insn *patch,
> + u32 len,
> + s32 insn_off_in_patch)
> {
> return ERR_PTR(-ENOTSUPP);
> }
> [...]
>
>
next prev parent reply other threads:[~2026-07-15 0:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 10:01 [PATCH bpf-next v5 00/10] bpf: add support for KASAN checks in JITed programs Alexis Lothoré (eBPF Foundation)
2026-07-09 10:01 ` [PATCH bpf-next v5 01/10] bpf: propagate original instruction offset when patching program Alexis Lothoré (eBPF Foundation)
2026-07-09 10:25 ` sashiko-bot
2026-07-15 0:47 ` Ihor Solodrai [this message]
2026-07-09 10:01 ` [PATCH bpf-next v5 02/10] bpf: mark instructions accessing program stack Alexis Lothoré (eBPF Foundation)
2026-07-09 10:35 ` sashiko-bot
2026-07-09 10:01 ` [PATCH bpf-next v5 03/10] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs Alexis Lothoré (eBPF Foundation)
2026-07-15 0:49 ` Ihor Solodrai
2026-07-09 10:01 ` [PATCH bpf-next v5 04/10] bpf, x86: add helper to emit kasan checks in x86 " Alexis Lothoré (eBPF Foundation)
2026-07-09 10:54 ` sashiko-bot
2026-07-15 0:53 ` Ihor Solodrai
2026-07-09 10:01 ` [PATCH bpf-next v5 05/10] bpf, x86: refactor BPF_ST management in do_jit Alexis Lothoré (eBPF Foundation)
2026-07-09 11:08 ` sashiko-bot
2026-07-09 10:01 ` [PATCH bpf-next v5 06/10] bpf, x86: emit KASAN checks into x86 JITed programs Alexis Lothoré (eBPF Foundation)
2026-07-09 11:20 ` sashiko-bot
2026-07-09 10:01 ` [PATCH bpf-next v5 07/10] bpf, x86: enable KASAN for JITed programs on x86 Alexis Lothoré (eBPF Foundation)
2026-07-09 11:29 ` sashiko-bot
2026-07-09 10:01 ` [PATCH bpf-next v5 08/10] selftests/bpf: add helpers for KASAN in JIT testing Alexis Lothoré (eBPF Foundation)
2026-07-09 11:35 ` sashiko-bot
2026-07-09 10:01 ` [PATCH bpf-next v5 09/10] selftests/bpf: move bpf_jit_harden helper into testing_helpers Alexis Lothoré (eBPF Foundation)
2026-07-09 10:01 ` [PATCH bpf-next v5 10/10] selftests/bpf: add tests to validate KASAN on JIT programs Alexis Lothoré (eBPF Foundation)
2026-07-09 11:52 ` sashiko-bot
2026-07-09 18:53 ` [PATCH bpf-next v5 00/10] bpf: add support for KASAN checks in JITed programs Borislav Petkov
2026-07-09 19:09 ` Alexis Lothoré
2026-07-15 0:43 ` Ihor Solodrai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bbbcbae7-a819-4f86-b116-6d5e31973a0e@linux.dev \
--to=ihor.solodrai@linux.dev \
--cc=alexis.lothore@bootlin.com \
--cc=andreyknvl@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bastien.curutchet@bootlin.com \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=ebpf@linuxfoundation.org \
--cc=eddyz87@gmail.com \
--cc=hpa@zytor.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mingo@redhat.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=tglx@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=x86@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.