From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A2F723E5584; Mon, 25 May 2026 09:05:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779699946; cv=none; b=Brich36AnOFAU34FfoGVdI8aXqJ+meJVfZaX4YHxfQk+Fh5/mKW9iz5IExVNFFv/fi7+9MmuUQplVrDhypl0D1x7pK1DHdrvjnxzu5okfVn5Ti/STZrdn/0/mkbJ7EF4SFa3+f/c1kh+Kt5FzRd40lqtqOPfqpF8IVKwSrIPsFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779699946; c=relaxed/simple; bh=YGBgB8DKElrV4R88Fy3fqbu8+6iow6N9sAidpgWS8Vc=; h=Content-Type:Date:Message-Id:Subject:Cc:From:To:Mime-Version: References:In-Reply-To; b=r+7ZSwAg+s3VvmlbeQ6Kjr4rWyryda7WwHa1Pd+7phYh8PsAFPemaxvxziOgMUM2lGFPGsViPovwLPcjpeS6G0/8g2slQc9J4Xb67tLvZXkv46B1lsf0gFl1/gpnrU6N+ai7ZJ3V1vsYppcZ9SdexKmdlpjTCIkGalsUgdN9kbA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=Fx+Uvlj9; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="Fx+Uvlj9" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 92C751A36AE; Mon, 25 May 2026 09:05:34 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 54B44603DC; Mon, 25 May 2026 09:05:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id B71FC10812103; Mon, 25 May 2026 11:05:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1779699932; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=EbTl273WowpTVFd0f4oge0/+s8K6R22iN2Gqank6L1c=; b=Fx+Uvlj9hDV8t2hT+BbSnAxNsdOpOaJIechqvnvpMOkSitZzXRjbsdPmMEWqyKUFfSsFqJ 09p3+5rjCc8SD5giFz2CNAPnkmaK402kZ1+6NUodo6410UYt45sJg+eUEcarYV6jiVsG7K 3r7plioTNGCAIgXGCNJ+2+ZTHyduDJ07uQslX/NevZyhzexSjWxmYTd3uD3CWiJVY0Dx6L 1Io8kWVF0On9LOxU2++gFB1HzzqUg55GF2+VuffbtA126LB+ZWF26BfdlTvZICqiAoOO3B zd+yqqxctwthai14JAAAUMFcgFwq3eBOVqm4oxh90R+vs0N3KX+iOH5nwmbVzw== Content-Type: text/plain; charset=UTF-8 Date: Mon, 25 May 2026 11:05:16 +0200 Message-Id: Subject: Re: [PATCH RFC bpf-next 3/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs Cc: "Andrey Konovalov" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Martin KaFai Lau" , "Eduard Zingerman" , "Kumar Kartikeya Dwivedi" , "Song Liu" , "Yonghong Song" , "Jiri Olsa" , "John Fastabend" , "David S. Miller" , "David Ahern" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , "X86 ML" , "H. Peter Anvin" , "Shuah Khan" , "Maxime Coquelin" , "Alexandre Torgue" , "Andrey Ryabinin" , "Alexander Potapenko" , "Dmitry Vyukov" , "Vincenzo Frascino" , "Andrew Morton" , , "Bastien Curutchet" , "Thomas Petazzoni" , "Xu Kuohai" , "bpf" , "LKML" , "Network Development" , "open list:KERNEL SELFTEST FRAMEWORK" , , "linux-arm-kernel" , "kasan-dev" , "linux-mm" From: =?utf-8?q?Alexis_Lothor=C3=A9?= To: "Emil Tsalapatis" , =?utf-8?q?Alexis_Lothor=C3=A9?= , "Alexei Starovoitov" Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260413-kasan-v1-0-1a5831230821@bootlin.com> <20260413-kasan-v1-3-1a5831230821@bootlin.com> In-Reply-To: X-Last-TLS-Session-Version: TLSv1.3 On Fri May 22, 2026 at 7:13 PM CEST, Emil Tsalapatis wrote: > On Fri May 22, 2026 at 10:14 AM EDT, Alexis Lothor=C3=A9 wrote: >> On Tue Apr 14, 2026 at 4:38 PM CEST, Alexei Starovoitov wrote: >>> On Tue, Apr 14, 2026 at 6:24=E2=80=AFAM Alexis Lothor=C3=A9 >>> wrote: >>>> >>>> On Tue Apr 14, 2026 at 12:20 AM CEST, Andrey Konovalov wrote: >>>> > On Mon, Apr 13, 2026 at 8:29=E2=80=AFPM Alexis Lothor=C3=A9 (eBPF Fo= undation) >>>> > wrote: >> >> [...] >> >>>> >> +config BPF_JIT_KASAN >>>> >> + bool >>>> >> + depends on HAVE_EBPF_JIT_KASAN >>>> >> + default y if BPF_JIT && KASAN_GENERIC >>>> > >>>> > Should this be "depends on KASAN && KASAN_GENERIC"? >>>> >>>> Meaning, making it an explicit user-selectable option ? >>>> >>>> If so, the current design choice is voluntary and based on the feedbac= k >>>> received on the original RFC, where I have been suggested to >>>> automatically enable the KASAN instrumentation in BPF programs if KASA= N >>>> support is enabled in the kernel ([1]). But if a user-selectable toggl= e >>>> is eventually a better solution, I'm fine with changing it. >>> >>> Let's not add more config knobs. >>> Even this patch looks redundant. >>> Inside JIT do instrumentation when KASAN_GENERIC is set. >> >> (with quite some delay) I think it would be better to keep this new >> BPF_JIT_KASAN, because aside from the possibility to use it in >> bpf_jit_comp.c, it allows to update tests affected by KASAN >> instrumentation in a nicer way. For example, the test_loader subtests >> that monitor JITted instructions are confused by KASAN. I can either >> skip them or make them smarter when KASAN is enabled for BPF, but in >> both cases, it would be nicer to just adapt the behavior based on a >> generic CONFIG_BPF_JIT_KASAN, rather than sprinkling some "if >> jit_enabled AND CONFIG_KASAN_GENERIC AND ARCH_X86" in selftests. That >> still does not make it a config knob, that just creates an internal >> Kconfig option that is automatically turned on when KASAN and JIT are >> enabled at build time. > > Having a togglable config knob gives us the option to set up KASAN for > the kernel but not for BPF, and I don't see why we'd want that. Imo we ar= e > already paying the cost of KASAN for the rest of the kernel, there is no > incentive to not run it for the BPF JIT. Having to eat the complexity cos= t > in the selftests seems reasonable if the alternative means a cleaner > interface for the user (preventing them from choosing an unreasonable > combination of options). Again, this does not expose a togglable knob, this is a purely internal kconfig, automatically enabled if CONFIG_KASAN_GENERIC is set and if the architecture-specific Kconfig defines HAVE_EBPF_JIT_KASAN (since we want it for x86 only), and there would be no way to enable KASAN for kernel only and not for BPF, or the other way around. What I am proposing is just an internal, architecture-agnostice kconfig to avoid conditioning some selftests to any architecture.=20 Alexis --=20 Alexis Lothor=C3=A9, Bootlin Embedded Linux and Kernel engineering https://bootlin.com