The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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);
>  }
> [...]
>  
> 


  reply	other threads:[~2026-07-15  0:47 UTC|newest]

Thread overview: 17+ 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-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: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-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 10:01 ` [PATCH bpf-next v5 06/10] bpf, x86: emit KASAN checks into x86 JITed programs Alexis Lothoré (eBPF Foundation)
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 10:01 ` [PATCH bpf-next v5 08/10] selftests/bpf: add helpers for KASAN in JIT testing Alexis Lothoré (eBPF Foundation)
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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox