From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta1.migadu.com (out-179.mta1.migadu.com [95.215.58.179]) (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 6BA8526B2DA for ; Fri, 24 Apr 2026 23:31:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777073521; cv=none; b=oevu10zutzu8SVFs8ljqNFO8+GLxOMVy9Vr1Ou27iro7/LBtFR0q11tdT1Nl/mZScdyTZDtVLOtrg98X6khYUPcAZz7ZhhJEiqelkH/FgUcRq66gMoUUbNRPgpchEVaasBPawTfdhWr+awVNbgkzbSngUHcOmuq4Xh/EBH/7Obk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777073521; c=relaxed/simple; bh=HblVc0QZVcSH+BEhdYmIe+eu3V5O05SC87J/OgoXbNg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ouuxexNJObo7J5HoVlroFQxrcZu4UNdoJ/P5VDNQXts/Z2ux9VB7zBT7swLGetaeO0Rj36YopDCYGs3HaMSsCWLTCvAteGGwfvpkkXj7zDDdQGGrdIngA1tMnXnqbutdtT5tiL2+Zf07qkIzkf6MpjoCrTCsz7j7cskPWAQgN/0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=FWyOdMQC; arc=none smtp.client-ip=95.215.58.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="FWyOdMQC" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1777073506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zyUuyE7w6pvvtI2U755rVQDGqOG1TjZmAAoWkbcJ3pw=; b=FWyOdMQChNJACKlHSUigRbF+UkaZINGXAnfgG0l27LLGRf/hYjHu/Lxkyy0R7Svov/3cgV ca7lKrp+oJsiAffpgj9aIdrEaU8SwwAp8RbrsigFrfnx1EjvABSU63IFjcjHzxaGMsifyR FfCrsxV2p8KUbJc33PxkbcHVFDmYG7c= Date: Fri, 24 Apr 2026 16:31:29 -0700 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers To: Alexei Starovoitov , Andrey Konovalov Cc: =?UTF-8?Q?Alexis_Lothor=C3=A9?= , 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 , ebpf@linuxfoundation.org, Bastien Curutchet , Thomas Petazzoni , Xu Kuohai , bpf , LKML , Network Development , "open list:KERNEL SELFTEST FRAMEWORK" , linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel , kasan-dev , linux-mm References: <20260413-kasan-v1-0-1a5831230821@bootlin.com> <20260413-kasan-v1-1-1a5831230821@bootlin.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ihor Solodrai In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 4/19/26 3:51 PM, Alexei Starovoitov wrote: > On Sun, Apr 19, 2026 at 2:49 PM Andrey Konovalov wrote: >> >> On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov >> wrote: >>> >>> I think we're talking past each other. >>> We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS. >>> We're not going to modify arm64 JIT at all. >>> >>> This is purely KASAN_GENRIC and only on x86-64. >>> JIT will emit exactly what compilers emit for generic >>> which is __asan_load/store. This is as stable ABI as it can get >>> and we don't want to deviate from it. >> >> OK, I supposed that's fair. You did throw me off point with your >> performance comment. But if you decide to add SW_TAGS support at some >> point, I think this discussion needs to be revisited. >> >> But please add a comment saying that those functions are only exposed >> for BPF JIT and they are not supposed to be used by other parts of the >> kernel. And in case you do end up adding a new config option, guard >> the public declarations by a corresponding ifdef. > > I feel concerns of misuse are overblown. > Being in include/linux/kasan.h doesn't make them free-for-all > all of a sudden, but if you prefer we can just copy paste: > +void __asan_load1(void *p); > +void __asan_store1(void *p); > into bpf_jit_comp.c > >>> The goal here is to find bugs in the verifier. >>> If something got past it, that shouldn't have, >>> kasan generic on x86-64 is enough. >> >> FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code. > > Ohh. Good point. Looks like modern arm64 cpus in public clouds > don't have that enabled, so one would need pixel phone to > catch verifier bugs via hw_tags. This comment got me curious, and acckktually if we *really* want to, we can get some KASAN_HW_TAGS testing for BPF already. The first option is emulation, since QEMU supports MTE [1], e.g.: qemu-system-aarch64 -machine virt,mte=on ... This is of course slow, because it runs in software, so it's infeasible to run this for every signle patch on BPF CI. But we could run it on schedule on the base branches or smth like that. [1] https://qemu-project.gitlab.io/qemu/system/arm/virt.html The second option is set up an AmpereOne machine on Oracle Cloud (assuming they are available, haven't checked), because apparently [2] those CPUs run with MTE. It's a bunch of infra work and spending, but it is doable if it was a priority. [2] https://arxiv.org/abs/2511.17773 > So we still need this x86-specific jit kasan. > I guess eventually it can be removed when hw_tags support is widespread.