From nobody Sun Dec 14 11:11:55 2025 Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch [79.135.106.31]) (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 832E1359FB5 for ; Wed, 29 Oct 2025 19:06:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.31 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764765; cv=none; b=frr0xAIFIec0XRPQOIThvBl5QzINLw0FyfTEiTuGNPxSmDOZbA4/FiXc8/OqV2w4W0VfnxT9XGzJ5oAhVYtA9Iw8ZBfGkzLXxVt1Na+B0O4lNWolJ9B3yw5IAA4O53zNAECaTXTOELB0ySIeqPJLr4SxRArI/3VXNl8eV/H2+rQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764765; c=relaxed/simple; bh=bMT6zwC9CBlFeLlkzXFrhE34J++x8Mj3alXKXMT5fIg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Hv90gJCp46IGgzbemxnwUIuEAOYInaMekJvP1jcbc3GLG0Apy7MsiQ7r5v4qjcMoKZh+CAF67QFgHGZuRBu0sXQqDZOTE71BIjxAB10Vb27SFCS4Dls3gSLbx3skPnb7GhTLqwM+YIDsIN1Qw5tukEhyAj/z1Joc52mr2ZDv8Qs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=fFgp0OHh; arc=none smtp.client-ip=79.135.106.31 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="fFgp0OHh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761764754; x=1762023954; bh=rr0Rm1n5HeBo5Fap/+IfVyHkvEn5nn0dcbxf514Q+kg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=fFgp0OHhcEPVlbbfupp7L0/UqzlPp2RufUT4rPPgcExkOWMJvc4oNZYRsMnJtLaiq tbZ0pJJzf7+iztM4ZLjdgxVnfM0mU6sf7aJcNlMahV5ULYqRdQak8/GsfTRouV/FV6 Rs3i2/tvdQy39XdXhteb1Q2psCmSv2YN7LhtWCCQ7XWYMeotnXT6CCvT66EtLFz+NN sdhEsdTaaCaHmgD+5tvbCHk0oBbsVLiQdk1opgevss+X0r7JVDeWWz63T8Rl3NBTQs fXUxKPqTm1DzR2rgkTnD11K7i77mRTHyM41THQ7Jcuwksy4ckzfzi12AR2jyyGpRiX +IffcE9sHZTTA== Date: Wed, 29 Oct 2025 19:05:49 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me, stable@vger.kernel.org, Baoquan He Subject: [PATCH v6 01/18] kasan: Unpoison pcpu chunks with base address tag Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: aef5b12294c25038010fe20ffdc227c541613b14 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman The problem presented here is related to NUMA systems and tag-based KASAN modes - software and hardware ones. It can be explained in the following points: 1. There can be more than one virtual memory chunk. 2. Chunk's base address has a tag. 3. The base address points at the first chunk and thus inherits the tag of the first chunk. 4. The subsequent chunks will be accessed with the tag from the first chunk. 5. Thus, the subsequent chunks need to have their tag set to match that of the first chunk. Refactor code by moving it into a helper in preparation for the actual fix. Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: # 6.1+ Signed-off-by: Maciej Wieczor-Retman Tested-by: Baoquan He --- Changelog v6: - Add Baoquan's tested-by tag. - Move patch to the beginning of the series as it is a fix. - Move the refactored code to tags.c because both software and hardware modes compile it. - Add fixes tag. Changelog v4: - Redo the patch message numbered list. - Do the refactoring in this patch and move additions to the next new one. Changelog v3: - Remove last version of this patch that just resets the tag on base_addr and add this patch that unpoisons all areas with the same tag instead. include/linux/kasan.h | 10 ++++++++++ mm/kasan/tags.c | 11 +++++++++++ mm/vmalloc.c | 4 +--- 3 files changed, 22 insertions(+), 3 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index d12e1a5f5a9a..b00849ea8ffd 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -614,6 +614,13 @@ static __always_inline void kasan_poison_vmalloc(const= void *start, __kasan_poison_vmalloc(start, size); } =20 +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms); +static __always_inline void kasan_unpoison_vmap_areas(struct vm_struct **v= ms, int nr_vms) +{ + if (kasan_enabled()) + __kasan_unpoison_vmap_areas(vms, nr_vms); +} + #else /* CONFIG_KASAN_VMALLOC */ =20 static inline void kasan_populate_early_vm_area_shadow(void *start, @@ -638,6 +645,9 @@ static inline void *kasan_unpoison_vmalloc(const void *= start, static inline void kasan_poison_vmalloc(const void *start, unsigned long s= ize) { } =20 +static inline void kasan_unpoison_vmap_areas(struct vm_struct **vms, int n= r_vms) +{ } + #endif /* CONFIG_KASAN_VMALLOC */ =20 #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c index b9f31293622b..ecc17c7c675a 100644 --- a/mm/kasan/tags.c +++ b/mm/kasan/tags.c @@ -18,6 +18,7 @@ #include #include #include +#include =20 #include "kasan.h" #include "../slab.h" @@ -146,3 +147,13 @@ void __kasan_save_free_info(struct kmem_cache *cache, = void *object) { save_stack_info(cache, object, 0, true); } + +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms) +{ + int area; + + for (area =3D 0 ; area < nr_vms ; area++) { + kasan_poison(vms[area]->addr, vms[area]->size, + arch_kasan_get_tag(vms[area]->addr), false); + } +} diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 798b2ed21e46..934c8bfbcebf 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4870,9 +4870,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned l= ong *offsets, * With hardware tag-based KASAN, marking is skipped for * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc(). */ - for (area =3D 0; area < nr_vms; area++) - vms[area]->addr =3D kasan_unpoison_vmalloc(vms[area]->addr, - vms[area]->size, KASAN_VMALLOC_PROT_NORMAL); + kasan_unpoison_vmap_areas(vms, nr_vms); =20 kfree(vas); return vms; --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch [109.224.244.17]) (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 8DAF0358D3D; Wed, 29 Oct 2025 19:06:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764784; cv=none; b=Z64qn7weCdgsS2xPxriQSZO8+7tqrKmOGsFDmPIYEcih/NVx+/qYrsAF5pKiUvqadf8SjFDv36tTV6ukvyin4MWRuh/+3YbQLXwoVY1Pxw+ScchgxJr+xGfp72PqOZkVmb6TQPzqYo/sacBSMv0Uf90Bgj5IobYxr8QHnGz8Ccg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764784; c=relaxed/simple; bh=X4z1GYkQrRVKx5pqYKCrGoe/bG8bmW9/6rB10Yrnyzg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=neGhl3TIrsGQQDXDWfLGu533Jr2V3vKfhx/Jz3V0GxOuxttX7okArr6jG6QroC2b9NasE1k9R31XSec7OEwKr3PCXwWKNe2gTjX3ak0R++vbyssWDjLgqewqLpIPHcWLAlsSKXc3uHeNM0xjZVkUDutamjYIN+R9gtMd7/ojnTo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=auxqsyOv; arc=none smtp.client-ip=109.224.244.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="auxqsyOv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761764770; x=1762023970; bh=oOT+8LaCSd2bsGWZH31RqkbowzlJMvnmRkALmEb4OMQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=auxqsyOvljSpXFTF5AKB3T/509bEa7/sfm3pUYNafcxp0ATbiM7w+PvdgHqDzP/Kl o6m94wJHeNA3LtEU9nJ3AbSjzlGm7hiKBmLb/V/GAJmJs7bw09PVZ8hQvZKOkhPZvg DJMBZlr4c42lwpCP6cG0IYpaei1wF90rYUs7RQpjzwhRHBhBgw2CbJTJkF9OyZXbaZ yfuwOUsn32t9bC5lYqxSFDkgHGelKaEZELumFwoYqF2EusJKk8QLDQkIBqE9T1z3V5 wXfTIeT/vk723bJXmhmoHgApPMBuwmceI0urqM/axJShS22fMn8OyttRP9uyR911Xi er2jNGKegxn+g== Date: Wed, 29 Oct 2025 19:06:03 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me, stable@vger.kernel.org, Baoquan He Subject: [PATCH v6 02/18] kasan: Unpoison vms[area] addresses with a common tag Message-ID: <932121edc75be8e2038d64ecb4853df2e2b258df.1761763681.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: b78f8be95b4a3268cc028d63fcca55df4e5c6664 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman The problem presented here is related to NUMA systems and tag-based KASAN modes - software and hardware ones. It can be explained in the following points: 1. There can be more than one virtual memory chunk. 2. Chunk's base address has a tag. 3. The base address points at the first chunk and thus inherits the tag of the first chunk. 4. The subsequent chunks will be accessed with the tag from the first chunk. 5. Thus, the subsequent chunks need to have their tag set to match that of the first chunk. Unpoison all vms[]->addr memory and pointers with the same tag to resolve the mismatch. Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: # 6.1+ Signed-off-by: Maciej Wieczor-Retman Tested-by: Baoquan He --- Changelog v6: - Add Baoquan's tested-by tag. - Move patch to the beginning of the series as it is a fix. - Add fixes tag. mm/kasan/tags.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c index ecc17c7c675a..c6b40cbffae3 100644 --- a/mm/kasan/tags.c +++ b/mm/kasan/tags.c @@ -148,12 +148,20 @@ void __kasan_save_free_info(struct kmem_cache *cache,= void *object) save_stack_info(cache, object, 0, true); } =20 +/* + * A tag mismatch happens when calculating per-cpu chunk addresses, because + * they all inherit the tag from vms[0]->addr, even when nr_vms is bigger + * than 1. This is a problem because all the vms[]->addr come from separate + * allocations and have different tags so while the calculated address is + * correct the tag isn't. + */ void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms) { int area; =20 for (area =3D 0 ; area < nr_vms ; area++) { kasan_poison(vms[area]->addr, vms[area]->size, - arch_kasan_get_tag(vms[area]->addr), false); + arch_kasan_get_tag(vms[0]->addr), false); + arch_kasan_set_tag(vms[area]->addr, arch_kasan_get_tag(vms[0]->addr)); } } --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch [79.135.106.31]) (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 858F93596F0 for ; Wed, 29 Oct 2025 19:06:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.31 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764791; cv=none; b=m4sSZyarFjiMowJNmo+cH1GGUPhLdIJmw8722kpO6Mi4Pl8Zu3002hdWbAgqS1Qit4PWXvg8/Tv7QRdlEXj89TESi8J+KblR3Dr1/vvz3dwBNlxPx+SvaFUF5/9J3TCb9Uv2KOFBKVB8SRvRyk+VdcQqM9XRT6nQzSoCvcHsDlg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764791; c=relaxed/simple; bh=bJqOLRh5AHXtNPhQL4KECEBFIG6XjKIdfPp+UO0i17o=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dQr2nwpKHqH/EInPDkk2zdyLG8inCEHPQ67rKJkq5cAmZ1G7GN57Xt2BmDUNWqdNa85RUsYuzyr5nKXJl0ZsD8MkayPwVwFbgVIs5z6V6Jhasm+DRb/63ZmxGlZiVL4Nja1VZ6VJrlCKDTko6obGSdH1fJFRQxrHatJusPN7HGE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=H4tX2CgX; arc=none smtp.client-ip=79.135.106.31 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="H4tX2CgX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761764786; x=1762023986; bh=jxLQWxZR1uUIJx1zLFGYnHCjTfyYOaAydFAYRdFzgVE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=H4tX2CgX2I46gjCYLXUey1izXUjeYYlVYJLkj6haus0rWX1Ik/lAVr4Ep8q33tSLR U6vGRWtoKELsOGMIDVJkARcEln+7pVGxbgUevhvqWXYL6Ib8pMQ2jtbrmkwjkfvXhL l5AtZ+pi06lU+HHuyy7mbuH7kGYp6NpTX6eiGgjWCGttWb+vaJ10/LENS2igc6PgDO up6HXVnm175PpnjYVxIFu2VDJZZ6XfePsrl6RZRn+MRWw1cojvOeOaRVSst1cnCtvB xxCtJpb+O28I+6ulCMBXklDx4NJoW3FMVrnxePy7aMv7RIIgTLzfdkhx1xmqddzP0r dHvmMrlRp8MUA== Date: Wed, 29 Oct 2025 19:06:17 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 03/18] kasan: sw_tags: Use arithmetic shift for shadow computation Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: d92e0c1a55128f8d1bfda37556d8adda3911f1d0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Samuel Holland Currently, kasan_mem_to_shadow() uses a logical right shift, which turns canonical kernel addresses into non-canonical addresses by clearing the high KASAN_SHADOW_SCALE_SHIFT bits. The value of KASAN_SHADOW_OFFSET is then chosen so that the addition results in a canonical address for the shadow memory. For KASAN_GENERIC, this shift/add combination is ABI with the compiler, because KASAN_SHADOW_OFFSET is used in compiler-generated inline tag checks[1], which must only attempt to dereference canonical addresses. However, for KASAN_SW_TAGS there is some freedom to change the algorithm without breaking the ABI. Because TBI is enabled for kernel addresses, the top bits of shadow memory addresses computed during tag checks are irrelevant, and so likewise are the top bits of KASAN_SHADOW_OFFSET. This is demonstrated by the fact that LLVM uses a logical right shift in the tag check fast path[2] but a sbfx (signed bitfield extract) instruction in the slow path[3] without causing any issues. Using an arithmetic shift in kasan_mem_to_shadow() provides a number of benefits: 1) The memory layout doesn't change but is easier to understand. KASAN_SHADOW_OFFSET becomes a canonical memory address, and the shifted pointer becomes a negative offset, so KASAN_SHADOW_OFFSET =3D=3D KASAN_SHADOW_END regardless of the shift amount or the size of the virtual address space. 2) KASAN_SHADOW_OFFSET becomes a simpler constant, requiring only one instruction to load instead of two. Since it must be loaded in each function with a tag check, this decreases kernel text size by 0.5%. 3) This shift and the sign extension from kasan_reset_tag() can be combined into a single sbfx instruction. When this same algorithm change is applied to the compiler, it removes an instruction from each inline tag check, further reducing kernel text size by an additional 4.6%. These benefits extend to other architectures as well. On RISC-V, where the baseline ISA does not shifted addition or have an equivalent to the sbfx instruction, loading KASAN_SHADOW_OFFSET is reduced from 3 to 2 instructions, and kasan_mem_to_shadow(kasan_reset_tag(addr)) similarly combines two consecutive right shifts. Link: https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Tr= ansforms/Instrumentation/AddressSanitizer.cpp#L1316 [1] Link: https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Tr= ansforms/Instrumentation/HWAddressSanitizer.cpp#L895 [2] Link: https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Ta= rget/AArch64/AArch64AsmPrinter.cpp#L669 [3] Signed-off-by: Samuel Holland Signed-off-by: Maciej Wieczor-Retman Acked-by: Catalin Marinas --- Changelog v6: (Maciej) - Add Catalin's acked-by. - Move x86 gdb snippet here from the last patch. Changelog v5: (Maciej) - (u64) -> (unsigned long) in report.c Changelog v4: (Maciej) - Revert x86 to signed mem_to_shadow mapping. - Remove last two paragraphs since they were just poorer duplication of the comments in kasan_non_canonical_hook(). Changelog v3: (Maciej) - Fix scripts/gdb/linux/kasan.py so the new signed mem_to_shadow() is reflected there. - Fix Documentation/arch/arm64/kasan-offsets.sh to take new offsets into account. - Made changes to the kasan_non_canonical_hook() according to upstream discussion. Settled on overflow on both ranges and separate checks for x86 and arm. Changelog v2: (Maciej) - Correct address range that's checked in kasan_non_canonical_hook(). Adjust the comment inside. - Remove part of comment from arch/arm64/include/asm/memory.h. - Append patch message paragraph about the overflow in kasan_non_canonical_hook(). Documentation/arch/arm64/kasan-offsets.sh | 8 +++-- arch/arm64/Kconfig | 10 +++---- arch/arm64/include/asm/memory.h | 14 ++++++++- arch/arm64/mm/kasan_init.c | 7 +++-- include/linux/kasan.h | 10 +++++-- mm/kasan/report.c | 36 ++++++++++++++++++++--- scripts/gdb/linux/kasan.py | 5 +++- scripts/gdb/linux/mm.py | 5 ++-- 8 files changed, 76 insertions(+), 19 deletions(-) mode change 100644 =3D> 100755 Documentation/arch/arm64/kasan-offsets.sh diff --git a/Documentation/arch/arm64/kasan-offsets.sh b/Documentation/arch= /arm64/kasan-offsets.sh old mode 100644 new mode 100755 index 2dc5f9e18039..ce777c7c7804 --- a/Documentation/arch/arm64/kasan-offsets.sh +++ b/Documentation/arch/arm64/kasan-offsets.sh @@ -5,8 +5,12 @@ =20 print_kasan_offset () { printf "%02d\t" $1 - printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \ - - (1 << (64 - 32 - $2)) )) + if [[ $2 -ne 4 ]] then + printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \ + - (1 << (64 - 32 - $2)) )) + else + printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) )) + fi } =20 echo KASAN_SHADOW_SCALE_SHIFT =3D 3 diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 6663ffd23f25..ac50ba2d760b 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -433,11 +433,11 @@ config KASAN_SHADOW_OFFSET default 0xdffffe0000000000 if ARM64_VA_BITS_42 && !KASAN_SW_TAGS default 0xdfffffc000000000 if ARM64_VA_BITS_39 && !KASAN_SW_TAGS default 0xdffffff800000000 if ARM64_VA_BITS_36 && !KASAN_SW_TAGS - default 0xefff800000000000 if (ARM64_VA_BITS_48 || (ARM64_VA_BITS_52 && != ARM64_16K_PAGES)) && KASAN_SW_TAGS - default 0xefffc00000000000 if (ARM64_VA_BITS_47 || ARM64_VA_BITS_52) && A= RM64_16K_PAGES && KASAN_SW_TAGS - default 0xeffffe0000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS - default 0xefffffc000000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS - default 0xeffffff800000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS + default 0xffff800000000000 if (ARM64_VA_BITS_48 || (ARM64_VA_BITS_52 && != ARM64_16K_PAGES)) && KASAN_SW_TAGS + default 0xffffc00000000000 if (ARM64_VA_BITS_47 || ARM64_VA_BITS_52) && A= RM64_16K_PAGES && KASAN_SW_TAGS + default 0xfffffe0000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS + default 0xffffffc000000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS + default 0xfffffff800000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS default 0xffffffffffffffff =20 config UNWIND_TABLES diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memor= y.h index f1505c4acb38..7bbebde59a75 100644 --- a/arch/arm64/include/asm/memory.h +++ b/arch/arm64/include/asm/memory.h @@ -89,7 +89,15 @@ * * KASAN_SHADOW_END is defined first as the shadow address that correspond= s to * the upper bound of possible virtual kernel memory addresses UL(1) << 64 - * according to the mapping formula. + * according to the mapping formula. For Generic KASAN, the address in the + * mapping formula is treated as unsigned (part of the compiler's ABI), so= the + * end of the shadow memory region is at a large positive offset from + * KASAN_SHADOW_OFFSET. For Software Tag-Based KASAN, the address in the + * formula is treated as signed. Since all kernel addresses are negative, = they + * map to shadow memory below KASAN_SHADOW_OFFSET, making KASAN_SHADOW_OFF= SET + * itself the end of the shadow memory region. (User pointers are positive= and + * would map to shadow memory above KASAN_SHADOW_OFFSET, but shadow memory= is + * not allocated for them.) * * KASAN_SHADOW_START is defined second based on KASAN_SHADOW_END. The sha= dow * memory start must map to the lowest possible kernel virtual memory addr= ess @@ -100,7 +108,11 @@ */ #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS) #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL) +#ifdef CONFIG_KASAN_GENERIC #define KASAN_SHADOW_END ((UL(1) << (64 - KASAN_SHADOW_SCALE_SHIFT)) + KAS= AN_SHADOW_OFFSET) +#else +#define KASAN_SHADOW_END KASAN_SHADOW_OFFSET +#endif #define _KASAN_SHADOW_START(va) (KASAN_SHADOW_END - (UL(1) << ((va) - KASA= N_SHADOW_SCALE_SHIFT))) #define KASAN_SHADOW_START _KASAN_SHADOW_START(vabits_actual) #define PAGE_END KASAN_SHADOW_START diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c index abeb81bf6ebd..937f6eb8115b 100644 --- a/arch/arm64/mm/kasan_init.c +++ b/arch/arm64/mm/kasan_init.c @@ -198,8 +198,11 @@ static bool __init root_level_aligned(u64 addr) /* The early shadow maps everything to a single page of zeroes */ asmlinkage void __init kasan_early_init(void) { - BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=3D - KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT))); + if (IS_ENABLED(CONFIG_KASAN_GENERIC)) + BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=3D + KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT))); + else + BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=3D KASAN_SHADOW_END); BUILD_BUG_ON(!IS_ALIGNED(_KASAN_SHADOW_START(VA_BITS), SHADOW_ALIGN)); BUILD_BUG_ON(!IS_ALIGNED(_KASAN_SHADOW_START(VA_BITS_MIN), SHADOW_ALIGN)); BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, SHADOW_ALIGN)); diff --git a/include/linux/kasan.h b/include/linux/kasan.h index b00849ea8ffd..952ade776e51 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -61,8 +61,14 @@ int kasan_populate_early_shadow(const void *shadow_start, #ifndef kasan_mem_to_shadow static inline void *kasan_mem_to_shadow(const void *addr) { - return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT) - + KASAN_SHADOW_OFFSET; + void *scaled; + + if (IS_ENABLED(CONFIG_KASAN_GENERIC)) + scaled =3D (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT); + else + scaled =3D (void *)((long)addr >> KASAN_SHADOW_SCALE_SHIFT); + + return KASAN_SHADOW_OFFSET + scaled; } #endif =20 diff --git a/mm/kasan/report.c b/mm/kasan/report.c index 62c01b4527eb..50d487a0687a 100644 --- a/mm/kasan/report.c +++ b/mm/kasan/report.c @@ -642,11 +642,39 @@ void kasan_non_canonical_hook(unsigned long addr) const char *bug_type; =20 /* - * All addresses that came as a result of the memory-to-shadow mapping - * (even for bogus pointers) must be >=3D KASAN_SHADOW_OFFSET. + * For Generic KASAN, kasan_mem_to_shadow() uses the logical right shift + * and never overflows with the chosen KASAN_SHADOW_OFFSET values (on + * both x86 and arm64). Thus, the possible shadow addresses (even for + * bogus pointers) belong to a single contiguous region that is the + * result of kasan_mem_to_shadow() applied to the whole address space. */ - if (addr < KASAN_SHADOW_OFFSET) - return; + if (IS_ENABLED(CONFIG_KASAN_GENERIC)) { + if (addr < (unsigned long)kasan_mem_to_shadow((void *)(0UL)) || + addr > (unsigned long)kasan_mem_to_shadow((void *)(~0UL))) + return; + } + + /* + * For Software Tag-Based KASAN, kasan_mem_to_shadow() uses the + * arithmetic shift. Normally, this would make checking for a possible + * shadow address complicated, as the shadow address computation + * operation would overflow only for some memory addresses. However, due + * to the chosen KASAN_SHADOW_OFFSET values and the fact the + * kasan_mem_to_shadow() only operates on pointers with the tag reset, + * the overflow always happens. + * + * For arm64, the top byte of the pointer gets reset to 0xFF. Thus, the + * possible shadow addresses belong to a region that is the result of + * kasan_mem_to_shadow() applied to the memory range + * [0xFF000000000000, 0xFFFFFFFFFFFFFFFF]. Despite the overflow, the + * resulting possible shadow region is contiguous, as the overflow + * happens for both 0xFF000000000000 and 0xFFFFFFFFFFFFFFFF. + */ + if (IS_ENABLED(CONFIG_KASAN_SW_TAGS) && IS_ENABLED(CONFIG_ARM64)) { + if (addr < (unsigned long)kasan_mem_to_shadow((void *)(0xFFUL << 56)) || + addr > (unsigned long)kasan_mem_to_shadow((void *)(~0UL))) + return; + } =20 orig_addr =3D (unsigned long)kasan_shadow_to_mem((void *)addr); =20 diff --git a/scripts/gdb/linux/kasan.py b/scripts/gdb/linux/kasan.py index 56730b3fde0b..4b86202b155f 100644 --- a/scripts/gdb/linux/kasan.py +++ b/scripts/gdb/linux/kasan.py @@ -7,7 +7,8 @@ # =20 import gdb -from linux import constants, mm +from linux import constants, utils, mm +from ctypes import c_int64 as s64 =20 def help(): t =3D """Usage: lx-kasan_mem_to_shadow [Hex memory addr] @@ -39,6 +40,8 @@ class KasanMemToShadow(gdb.Command): else: help() def kasan_mem_to_shadow(self, addr): + if constants.CONFIG_KASAN_SW_TAGS and not utils.is_target_arch('x8= 6'): + addr =3D s64(addr) return (addr >> self.p_ops.KASAN_SHADOW_SCALE_SHIFT) + self.p_ops.= KASAN_SHADOW_OFFSET =20 KasanMemToShadow() diff --git a/scripts/gdb/linux/mm.py b/scripts/gdb/linux/mm.py index 7571aebbe650..2e63f3dedd53 100644 --- a/scripts/gdb/linux/mm.py +++ b/scripts/gdb/linux/mm.py @@ -110,12 +110,13 @@ class aarch64_page_ops(): self.KERNEL_END =3D gdb.parse_and_eval("_end") =20 if constants.LX_CONFIG_KASAN_GENERIC or constants.LX_CONFIG_KASAN_= SW_TAGS: + self.KASAN_SHADOW_OFFSET =3D constants.LX_CONFIG_KASAN_SHADOW_= OFFSET if constants.LX_CONFIG_KASAN_GENERIC: self.KASAN_SHADOW_SCALE_SHIFT =3D 3 + self.KASAN_SHADOW_END =3D (1 << (64 - self.KASAN_SHADOW_SC= ALE_SHIFT)) + self.KASAN_SHADOW_OFFSET else: self.KASAN_SHADOW_SCALE_SHIFT =3D 4 - self.KASAN_SHADOW_OFFSET =3D constants.LX_CONFIG_KASAN_SHADOW_= OFFSET - self.KASAN_SHADOW_END =3D (1 << (64 - self.KASAN_SHADOW_SCALE_= SHIFT)) + self.KASAN_SHADOW_OFFSET + self.KASAN_SHADOW_END =3D self.KASAN_SHADOW_OFFSET self.PAGE_END =3D self.KASAN_SHADOW_END - (1 << (self.vabits_a= ctual - self.KASAN_SHADOW_SCALE_SHIFT)) else: self.PAGE_END =3D self._PAGE_END(self.VA_BITS_MIN) --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch [79.135.106.30]) (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 3AC992E6CD7; Wed, 29 Oct 2025 19:06:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.30 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764805; cv=none; b=JfrsolimaBydeCcND1nXmdlrGPCxc+FDZbCI93SvJ07WSrTHRGh5E3Dko6ZYESbiXy4FlBbbjVhY6mZdq2NPApnSCrhO5k/gnbJpKPg/V8F2sR+2b+WXJ+C2Ebf+vbmVzhY6bKQfe4fLLJrV0Ub0MdYwo9+5bhwp1YREvSV+iI0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764805; c=relaxed/simple; bh=wwyHZ2RK4+tdqguT8sq3N+QdyLYVm5hVSL8mWJX3/AE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=tSTyYez9YGV+AcFwg0mC0a+CsZuQFDMw1gRnhVekVl9iG2r1WZ/E1Nx8JbtR01JSYD8wILmzKNzXjygXjFK1JVwHelMMFFsaouduuSnld4jNuGVEUq6ysxXuZui9BCkAqkPBCMfYHZB9N21KwxIVKi1zwfUwhkdtDb3f3z5jaTE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=pGVXX/VY; arc=none smtp.client-ip=79.135.106.30 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="pGVXX/VY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761764801; x=1762024001; bh=RT/zPmq8dzuzMSpg5XGcznppBgYR4y/21vyg9rTeyzk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=pGVXX/VYTWR44Wl1sG/O8IDygFTtrJhNXjWeLezoqqGkYg93K5hXzT1PokJx6a62h GV+r67xFAM4zXxfmJpWSg+F64ywdK83enI1wzWnczmBMFY5OzsI3s9yvN7mT2Td4Dh 7TyK6Vznu89HYA6GkMLZywdeGiiHscMs/4E8pcQkBgwWwHkh9pWdFp7Rt9jF1HxtdQ OMd4mrpIp0uXdoWQ5BDxmbbqnKomkHfV2zzEFu4RrOwaqx4IsoSWQ1IqwNNbeC3qV0 veI/fsLyEWuW5i6UByGv6InudSQ9k9UBxjAaTuvbgfCVVQPibgB5z0JnNq7hhrFh2B fHc1Ge225l1xQ== Date: Wed, 29 Oct 2025 19:06:33 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 04/18] kasan: sw_tags: Support tag widths less than 8 bits Message-ID: <8319582016f3e433bf7cd1c88ce7858c4a3c60fa.1761763681.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 5f5d346b6b1d7504801ff3b4ec51dbe636e94b26 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Samuel Holland Allow architectures to override KASAN_TAG_KERNEL in asm/kasan.h. This is needed on RISC-V, which supports 57-bit virtual addresses and 7-bit pointer tags. For consistency, move the arm64 MTE definition of KASAN_TAG_MIN to asm/kasan.h, since it is also architecture-dependent; RISC-V's equivalent extension is expected to support 7-bit hardware memory tags. Reviewed-by: Andrey Konovalov Signed-off-by: Samuel Holland Signed-off-by: Maciej Wieczor-Retman --- arch/arm64/include/asm/kasan.h | 6 ++++-- arch/arm64/include/asm/uaccess.h | 1 + include/linux/kasan-tags.h | 13 ++++++++----- 3 files changed, 13 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h index e1b57c13f8a4..4ab419df8b93 100644 --- a/arch/arm64/include/asm/kasan.h +++ b/arch/arm64/include/asm/kasan.h @@ -6,8 +6,10 @@ =20 #include #include -#include -#include + +#ifdef CONFIG_KASAN_HW_TAGS +#define KASAN_TAG_MIN 0xF0 /* minimum value for random tags */ +#endif =20 #define arch_kasan_set_tag(addr, tag) __tag_set(addr, tag) #define arch_kasan_reset_tag(addr) __tag_reset(addr) diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uacc= ess.h index 1aa4ecb73429..8f700a7dd2cd 100644 --- a/arch/arm64/include/asm/uaccess.h +++ b/arch/arm64/include/asm/uaccess.h @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include diff --git a/include/linux/kasan-tags.h b/include/linux/kasan-tags.h index 4f85f562512c..e07c896f95d3 100644 --- a/include/linux/kasan-tags.h +++ b/include/linux/kasan-tags.h @@ -2,13 +2,16 @@ #ifndef _LINUX_KASAN_TAGS_H #define _LINUX_KASAN_TAGS_H =20 +#include + +#ifndef KASAN_TAG_KERNEL #define KASAN_TAG_KERNEL 0xFF /* native kernel pointers tag */ -#define KASAN_TAG_INVALID 0xFE /* inaccessible memory tag */ -#define KASAN_TAG_MAX 0xFD /* maximum value for random tags */ +#endif + +#define KASAN_TAG_INVALID (KASAN_TAG_KERNEL - 1) /* inaccessible memory ta= g */ +#define KASAN_TAG_MAX (KASAN_TAG_KERNEL - 2) /* maximum value for random = tags */ =20 -#ifdef CONFIG_KASAN_HW_TAGS -#define KASAN_TAG_MIN 0xF0 /* minimum value for random tags */ -#else +#ifndef KASAN_TAG_MIN #define KASAN_TAG_MIN 0x00 /* minimum value for random tags */ #endif =20 --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch [109.224.244.16]) (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 6F239261B62; Wed, 29 Oct 2025 19:07:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764822; cv=none; b=HU+zVocHyBe0suTEsBjA3AX227xC27aiXXzy+dHVOjW5lfcRFjOOhhAlYJ2havpXhj3SKAC0JMl02uDM5XRDrAeYvYhhGF33Vuxaxy+bvDzoRLjgwB7w+du5Xevw90t7luTVKizIgTLzrzIaOG84tfe6gF8btMqWRfQn0SaLjdY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764822; c=relaxed/simple; bh=mlxnBtQuW4/i3OKXh4jLeblYDHucd5W1OUn5HztEK4M=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MMzgpI112KCevo8BIDLWo1JSCyknjcmrmByKbQYrfShev97vYXf/MPjOIBR2ztbWURuxqqSTEf7J/uSgsu4vhPsL9pheaQFNFVbbJpmsmj/LQmrA4WNzvlHkNR8isBsHo1oJgw4rVxZnww50KgM+exdc4jG8ChRDv3dec1EkV7s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=iIyqHUmB; arc=none smtp.client-ip=109.224.244.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="iIyqHUmB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761764817; x=1762024017; bh=UuVBFIvAqVGiw6UOZ0Oq2LH/B7F2B7f/ik0cOvmOtjs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=iIyqHUmBQXJaUQMu+N0NZRSCH0kBx2A+c75BMIdYkjFaKskam7OT5Wjd61R/gx1Xx Xz0BfxOeql9L47SHvCAkTWD8CiJ+CjosWQrVJYXj5LffB0359mhzcZDTk3guLEc1CS P0af2k465IeYSTRHH9BfuN5/rtI1csCf0L/rvSxUQ5Cyw8uCyP7Mzz+OLabhBWwsGl FCjPJ3WdW+JAXcyt3iYl4ylBSBFjo6RMPXpCvPqMBk6x7qS2DVGrYDrO89F2AEEiVk 28Kvfp7z51eeM83L/GI9KF+c19L/vN8JB6k/tf/liftNpp/hj1PWfhGBSR5c0xS25r LMiCrEx6G6R2g== Date: Wed, 29 Oct 2025 19:06:49 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 05/18] kasan: Fix inline mode for x86 tag-based mode Message-ID: <8681ee6683b1c65a1d5d65f21c66e63378806ba0.1761763681.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 57ed454739a234eef863007c4125f42148d9fdbb Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman The LLVM compiler uses hwasan-instrument-with-calls parameter to setup inline or outline mode in tag-based KASAN. If zeroed, it means the instrumentation implementation will be pasted into each relevant location along with KASAN related constants during compilation. If set to one all function instrumentation will be done with function calls instead. The default hwasan-instrument-with-calls value for the x86 architecture in the compiler is "1", which is not true for other architectures. Because of this, enabling inline mode in software tag-based KASAN doesn't work on x86 as the kernel script doesn't zero out the parameter and always sets up the outline mode. Explicitly zero out hwasan-instrument-with-calls when enabling inline mode in tag-based KASAN. Signed-off-by: Maciej Wieczor-Retman Reviewed-by: Andrey Konovalov Reviewed-by: Alexander Potapenko --- Changelog v6: - Add Andrey's Reviewed-by tag. Changelog v3: - Add this patch to the series. scripts/Makefile.kasan | 3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan index 0ba2aac3b8dc..e485814df3e9 100644 --- a/scripts/Makefile.kasan +++ b/scripts/Makefile.kasan @@ -76,8 +76,11 @@ CFLAGS_KASAN :=3D -fsanitize=3Dkernel-hwaddress RUSTFLAGS_KASAN :=3D -Zsanitizer=3Dkernel-hwaddress \ -Zsanitizer-recover=3Dkernel-hwaddress =20 +# LLVM sets hwasan-instrument-with-calls to 1 on x86 by default. Set it to= 0 +# when inline mode is enabled. ifdef CONFIG_KASAN_INLINE kasan_params +=3D hwasan-mapping-offset=3D$(KASAN_SHADOW_OFFSET) + kasan_params +=3D hwasan-instrument-with-calls=3D0 else kasan_params +=3D hwasan-instrument-with-calls=3D1 endif --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch [109.224.244.17]) (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 9B052357A4C for ; Wed, 29 Oct 2025 19:07:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764834; cv=none; b=nBaXmSrkJMTXNv3dT/+W/OQmAuypjtq63iXFaYvjyszQFj1Gez045DdX7DTWi1bfc3QludOTDeiYbFXBrW8L0mbu9VAEJB6yZ0aCjpq2X5aEpwLOGmQ/q+RTQjsI7SSOjhhZ2L6XATrfS6f+o7rA/cuVfcth4HMW1bAKluAtBxE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764834; c=relaxed/simple; bh=uGCpeSXg/TwzqC/G0Sv5pR2uEf/a3YnL7Q02GxMvD18=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QkU4SyspV2ER8EkuImi6SWerB17O5oh2RcIVNixwf2mGIlbbR9ndJBQQ5+G3PWDNqO/mFIE4gKnj4JQwqtTz3i6OIAALAF+PvlJhqFLpi+BLkGOZlQGIp8DFD6bdfOx2HTQpb4MMGw/e+Ews2cIgwCWHeOHJsplJzMf6D9wWQNs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=OLK+mYTZ; arc=none smtp.client-ip=109.224.244.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="OLK+mYTZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761764830; x=1762024030; bh=V+GI3JCHWjOQcFbXmMHTXI5iGSfAXcKKoBJ+NaZcg5c=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=OLK+mYTZss2HUSw9NfQJFmBZXPQpGyO18z4fzmKhditcec3bCsPrPoXyhQ2UsC2Ra rAl5/2CYQI+Y1mMVRPqPEuOOiBjJHK544HtwILnNJT5/FKFU/v2pjnyIqXshlSmKEc VadPr3Md0c5XXKXtYdnRBxE4zYRMSH50w+hN92Mg8Mv8P2KQAGZRBKBKqEStGqf0BM /anLMmHFeqGGLt/rMS4Jqu4Xq1dszXRzP7qoEacCQwdD5XaLd82s2oXhsRREEJrf5B 3rkW2LUFOlJ4uHEyTIgUZpV2j3EWms0GxjcIoQ0nALLhlo0Hqiht1iraRW9TnRf3oG iDVK81uAmCuwA== Date: Wed, 29 Oct 2025 19:07:05 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 06/18] x86/kasan: Add arch specific kasan functions Message-ID: <5be986faa12ed1176889c3ba25852c42674305f4.1761763681.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 78312123e49b3e9b61a0495ac0e750673eadf38b Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman KASAN's software tag-based mode needs multiple macros/functions to handle tag and pointer interactions - to set, retrieve and reset tags from the top bits of a pointer. Mimic functions currently used by arm64 but change the tag's position to bits [60:57] in the pointer. Signed-off-by: Maciej Wieczor-Retman Acked-by: Andrey Konovalov --- Changelog v6: - Remove empty line after ifdef CONFIG_KASAN_SW_TAGS - Add ifdef 64 bit to avoid problems in vdso32. - Add Andrey's Acked-by tag. Changelog v4: - Rewrite __tag_set() without pointless casts and make it more readable. Changelog v3: - Reorder functions so that __tag_*() etc are above the arch_kasan_*() ones. - Remove CONFIG_KASAN condition from __tag_set() arch/x86/include/asm/kasan.h | 42 ++++++++++++++++++++++++++++++++++-- 1 file changed, 40 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h index d7e33c7f096b..396071832d02 100644 --- a/arch/x86/include/asm/kasan.h +++ b/arch/x86/include/asm/kasan.h @@ -3,6 +3,8 @@ #define _ASM_X86_KASAN_H =20 #include +#include +#include #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL) #define KASAN_SHADOW_SCALE_SHIFT 3 =20 @@ -24,8 +26,43 @@ KASAN_SHADOW_SCALE_SHIFT))) =20 #ifndef __ASSEMBLER__ +#include +#include +#include + +#ifdef CONFIG_KASAN_SW_TAGS +#define __tag_shifted(tag) FIELD_PREP(GENMASK_ULL(60, 57), tag) +#define __tag_reset(addr) (sign_extend64((u64)(addr), 56)) +#define __tag_get(addr) ((u8)FIELD_GET(GENMASK_ULL(60, 57), (u64)addr)) +#else +#define __tag_shifted(tag) 0UL +#define __tag_reset(addr) (addr) +#define __tag_get(addr) 0 +#endif /* CONFIG_KASAN_SW_TAGS */ + +#ifdef CONFIG_64BIT +static inline void *__tag_set(const void *__addr, u8 tag) +{ + u64 addr =3D (u64)__addr; + + addr &=3D ~__tag_shifted(KASAN_TAG_MASK); + addr |=3D __tag_shifted(tag); + + return (void *)addr; +} +#else +static inline void *__tag_set(void *__addr, u8 tag) +{ + return __addr; +} +#endif + +#define arch_kasan_set_tag(addr, tag) __tag_set(addr, tag) +#define arch_kasan_reset_tag(addr) __tag_reset(addr) +#define arch_kasan_get_tag(addr) __tag_get(addr) =20 #ifdef CONFIG_KASAN + void __init kasan_early_init(void); void __init kasan_init(void); void __init kasan_populate_shadow_for_vaddr(void *va, size_t size, int nid= ); @@ -34,8 +71,9 @@ static inline void kasan_early_init(void) { } static inline void kasan_init(void) { } static inline void kasan_populate_shadow_for_vaddr(void *va, size_t size, int nid) { } -#endif =20 -#endif +#endif /* CONFIG_KASAN */ + +#endif /* __ASSEMBLER__ */ =20 #endif --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch [109.224.244.18]) (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 F401E3596F9 for ; Wed, 29 Oct 2025 19:07:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764852; cv=none; b=cfjBIPZyCoWscdg32DQ0gORxeKk/utBTCj/QAaChx9IK9x/DWa4+stNErnxJ23ycArOeAsQ3JAcSPaGccOAqDdjQSm5iJOVxZlXcNpAJe3HD317JF7RjQyHm84CkbdQ7Q2sGfKVjnKMIlbDD4lg2MRXGbFZXQvDpbQkYZjM3MGw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764852; c=relaxed/simple; bh=JqCzUyZ0QNBihHUXBSMPwH8gRHOq8dWLEy51Mzzfv0k=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=AV+OUnCeu6VS11OjuihXCu+B42zu6qEW7lSWgJSK3JidffV4CO1YL2D3O6/VwNLrcxog++ZhFkpzokArLPKyLoFH0qsse7fVhQlre8kzkqtHuMG5JraPE27znz/0rIDIVVJvEe2E0yWWKORLaA2uIehf31hwpMC6PVQ+hEHo5vw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=kVBnL3t8; arc=none smtp.client-ip=109.224.244.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="kVBnL3t8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761764845; x=1762024045; bh=lbXAxn7Fr4Nsk0Pj0RuqXVl7zH+aG4MTOYlJmhasqg0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=kVBnL3t8JvjQ9HqLZI8hjXHke1yeuJACxtQMIgo03RCuNpTJrog3nwzZuch3Sq2HX eplFtslhSeF1H9XtAz3TxhLc6rYpwoIwfwtCSB2izjzP5z4ouVdqY5oxIo9OQ9YfhX qoZE7Gx/tHaWOqcYpYKTMNgSLXDkK5d02/7j6xlwl3K+JI82dbPfEcEQ2wB0zOdp6e lpeOLa2anhhZTFZd5bLxzRN+RgujTzwyFrhLbahp3HIh2XgpHF+W2YfZ9IWQrn9F7P Jyb2XOVHcLarA36q7cAU+FE+SailOTdfiMn1UOHBwFbxw/Hba8Y36Fl1VihdBITwZk AsGfuPMCtIARw== Date: Wed, 29 Oct 2025 19:07:18 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 07/18] kasan: arm64: x86: Make special tags arch specific Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: ce29df287bb81048c364d183798873981c136eab Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman KASAN's tag-based mode defines multiple special tag values. They're reserved for: - Native kernel value. On arm64 it's 0xFF and it causes an early return in the tag checking function. - Invalid value. 0xFE marks an area as freed / unallocated. It's also the value that is used to initialize regions of shadow memory. - Max value. 0xFD is the highest value that can be randomly generated for a new tag. Metadata macro is also defined: - Tag width equal to 8. Tag-based mode on x86 is going to use 4 bit wide tags so all the above values need to be changed accordingly. Make native kernel tag arch specific for x86 and arm64. Replace hardcoded kernel tag value and tag width with macros in KASAN's non-arch specific code. Signed-off-by: Maciej Wieczor-Retman --- Changelog v6: - Add hardware tags KASAN_TAG_WIDTH value to the arm64 arch file. - Keep KASAN_TAG_MASK in the mmzone.h. - Remove ifndef from KASAN_SHADOW_INIT. Changelog v5: - Move KASAN_TAG_MIN to the arm64 kasan-tags.h for the hardware KASAN mode case. Changelog v4: - Move KASAN_TAG_MASK to kasan-tags.h. Changelog v2: - Remove risc-v from the patch. MAINTAINERS | 2 +- arch/arm64/include/asm/kasan-tags.h | 14 ++++++++++++++ arch/arm64/include/asm/kasan.h | 4 ---- arch/x86/include/asm/kasan-tags.h | 9 +++++++++ include/linux/kasan-tags.h | 10 +++++++++- include/linux/kasan.h | 3 +-- include/linux/mm.h | 6 +++--- include/linux/page-flags-layout.h | 9 +-------- 8 files changed, 38 insertions(+), 19 deletions(-) create mode 100644 arch/arm64/include/asm/kasan-tags.h create mode 100644 arch/x86/include/asm/kasan-tags.h diff --git a/MAINTAINERS b/MAINTAINERS index 3da2c26a796b..53cbc7534911 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13421,7 +13421,7 @@ L: kasan-dev@googlegroups.com S: Maintained B: https://bugzilla.kernel.org/buglist.cgi?component=3DSanitizers&product= =3DMemory%20Management F: Documentation/dev-tools/kasan.rst -F: arch/*/include/asm/*kasan.h +F: arch/*/include/asm/*kasan*.h F: arch/*/mm/kasan_init* F: include/linux/kasan*.h F: lib/Kconfig.kasan diff --git a/arch/arm64/include/asm/kasan-tags.h b/arch/arm64/include/asm/k= asan-tags.h new file mode 100644 index 000000000000..e6b5086e3f44 --- /dev/null +++ b/arch/arm64/include/asm/kasan-tags.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __ASM_KASAN_TAGS_H +#define __ASM_KASAN_TAGS_H + +#define KASAN_TAG_KERNEL 0xFF /* native kernel pointers tag */ + +#define KASAN_TAG_WIDTH 8 + +#ifdef CONFIG_KASAN_HW_TAGS +#define KASAN_TAG_MIN 0xF0 /* minimum value for random tags */ +#define KASAN_TAG_WIDTH 4 +#endif + +#endif /* ASM_KASAN_TAGS_H */ diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h index 4ab419df8b93..d2841e0fb908 100644 --- a/arch/arm64/include/asm/kasan.h +++ b/arch/arm64/include/asm/kasan.h @@ -7,10 +7,6 @@ #include #include =20 -#ifdef CONFIG_KASAN_HW_TAGS -#define KASAN_TAG_MIN 0xF0 /* minimum value for random tags */ -#endif - #define arch_kasan_set_tag(addr, tag) __tag_set(addr, tag) #define arch_kasan_reset_tag(addr) __tag_reset(addr) #define arch_kasan_get_tag(addr) __tag_get(addr) diff --git a/arch/x86/include/asm/kasan-tags.h b/arch/x86/include/asm/kasan= -tags.h new file mode 100644 index 000000000000..68ba385bc75c --- /dev/null +++ b/arch/x86/include/asm/kasan-tags.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __ASM_KASAN_TAGS_H +#define __ASM_KASAN_TAGS_H + +#define KASAN_TAG_KERNEL 0xF /* native kernel pointers tag */ + +#define KASAN_TAG_WIDTH 4 + +#endif /* ASM_KASAN_TAGS_H */ diff --git a/include/linux/kasan-tags.h b/include/linux/kasan-tags.h index e07c896f95d3..fe80fa8f3315 100644 --- a/include/linux/kasan-tags.h +++ b/include/linux/kasan-tags.h @@ -2,7 +2,15 @@ #ifndef _LINUX_KASAN_TAGS_H #define _LINUX_KASAN_TAGS_H =20 -#include +#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS) +#include +#endif + +#ifndef KASAN_TAG_WIDTH +#define KASAN_TAG_WIDTH 0 +#endif + +#define KASAN_TAG_MASK ((1UL << KASAN_TAG_WIDTH) - 1) =20 #ifndef KASAN_TAG_KERNEL #define KASAN_TAG_KERNEL 0xFF /* native kernel pointers tag */ diff --git a/include/linux/kasan.h b/include/linux/kasan.h index 952ade776e51..3c0c60ed5d5c 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -39,8 +39,7 @@ typedef unsigned int __bitwise kasan_vmalloc_flags_t; /* Software KASAN implementations use shadow memory. */ =20 #ifdef CONFIG_KASAN_SW_TAGS -/* This matches KASAN_TAG_INVALID. */ -#define KASAN_SHADOW_INIT 0xFE +#define KASAN_SHADOW_INIT KASAN_TAG_INVALID #else #define KASAN_SHADOW_INIT 0 #endif diff --git a/include/linux/mm.h b/include/linux/mm.h index d16b33bacc32..09538c7487f3 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1762,7 +1762,7 @@ static inline u8 page_kasan_tag(const struct page *pa= ge) =20 if (kasan_enabled()) { tag =3D (page->flags.f >> KASAN_TAG_PGSHIFT) & KASAN_TAG_MASK; - tag ^=3D 0xff; + tag ^=3D KASAN_TAG_KERNEL; } =20 return tag; @@ -1775,7 +1775,7 @@ static inline void page_kasan_tag_set(struct page *pa= ge, u8 tag) if (!kasan_enabled()) return; =20 - tag ^=3D 0xff; + tag ^=3D KASAN_TAG_KERNEL; old_flags =3D READ_ONCE(page->flags.f); do { flags =3D old_flags; @@ -1794,7 +1794,7 @@ static inline void page_kasan_tag_reset(struct page *= page) =20 static inline u8 page_kasan_tag(const struct page *page) { - return 0xff; + return KASAN_TAG_KERNEL; } =20 static inline void page_kasan_tag_set(struct page *page, u8 tag) { } diff --git a/include/linux/page-flags-layout.h b/include/linux/page-flags-l= ayout.h index 760006b1c480..b2cc4cb870e0 100644 --- a/include/linux/page-flags-layout.h +++ b/include/linux/page-flags-layout.h @@ -3,6 +3,7 @@ #define PAGE_FLAGS_LAYOUT_H =20 #include +#include #include =20 /* @@ -72,14 +73,6 @@ #define NODE_NOT_IN_PAGE_FLAGS 1 #endif =20 -#if defined(CONFIG_KASAN_SW_TAGS) -#define KASAN_TAG_WIDTH 8 -#elif defined(CONFIG_KASAN_HW_TAGS) -#define KASAN_TAG_WIDTH 4 -#else -#define KASAN_TAG_WIDTH 0 -#endif - #ifdef CONFIG_NUMA_BALANCING #define LAST__PID_SHIFT 8 #define LAST__PID_MASK ((1 << LAST__PID_SHIFT)-1) --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (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 8BFC63590B5; Wed, 29 Oct 2025 19:07:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.43.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764869; cv=none; b=CvL+u1TAgTamDAi0OYE/S8sAIbNKdI9SIC8D28KRyyZzE5eIkluG5vc9W08sa2qZVMwNKWpnfl4tuaF2SDHqmCyHiS01SK2kqkjKM+cScOgsGviLHBBkwRsJohptf0moPfTOcH2eUkno+OyCaiP+UNXdipq81IkVmklssr/hrOc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764869; c=relaxed/simple; bh=gaNXZp8CyQJ3XJXYSkh9xwZ1pMXf7iNAYXLNmmh0VKI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dkc/uzr9yScvTn8sfrepsFzFn7Ll3UTWuEg4U2oi7WPwLkPsAO0oK6OBGFNjuBok1XsRSXCIHOuP5UYbOrwbs1PGKSJ1paMWoGbniJZjehFqtq7vQ8slnFXs7Av8nB/BpIfF/PDIb55La5tu2axiHS3oLzXg9kSXcnt27eOVMe4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=oLFtUaeP; arc=none smtp.client-ip=185.70.43.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="oLFtUaeP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761764863; x=1762024063; bh=sFQWpkAgZ4WYl8uNu/8Fmdid7sZ+Bxs6DzYolFKr5rI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=oLFtUaePcdKPdIcWB++mjgoA1FYxZr+2qq4hruE3cTHdK9B3d+RcwNSKm4Yjzuean Yy3mXhLMxlUY79Y37OsojkJOCfOOwHoANbiDCLpmuEgEynKBfImp9SUS6yWy3g3D4+ ZWfCuzapxDyymtwWB1LxqIVav+eW6ttVRuFBHhxAyTJImw+MKe3v3cF7Py5MKMvy/W erm3j57lR0Z4dpzNDQPJ2WldIPuRsSCDx1m3pNOWYpjYPErDQAlXPG3R7vrqH1xbA4 d2dtAZhxuJk/uir+koJ2LsPFTm9IhIxQtSGaCQEf+N+oe3ms7MPhnPNrYi+DQPJaaa cQqb0wWO5S0ow== Date: Wed, 29 Oct 2025 19:07:34 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 08/18] x86/mm: Reset tag for virtual to physical address conversions Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: c34c086f0ceececd458efcce81b943565370c09a Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman Any place where pointer arithmetic is used to convert a virtual address into a physical one can raise errors if the virtual address is tagged. Reset the pointer's tag by sign extending the tag bits in macros that do pointer arithmetic in address conversions. There will be no change in compiled code with KASAN disabled since the compiler will optimize the __tag_reset() out. Signed-off-by: Maciej Wieczor-Retman Acked-by: Alexander Potapenko --- Changelog v5: - Move __tag_reset() calls into __phys_addr_nodebug() and __virt_addr_valid() instead of calling it on the arguments of higher level functions. Changelog v4: - Simplify page_to_virt() by removing pointless casts. - Remove change in __is_canonical_address() because it's taken care of in a later patch due to a LAM compatible definition of canonical. arch/x86/include/asm/page.h | 8 ++++++++ arch/x86/include/asm/page_64.h | 1 + arch/x86/mm/physaddr.c | 2 ++ 3 files changed, 11 insertions(+) diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h index 9265f2fca99a..bcf5cad3da36 100644 --- a/arch/x86/include/asm/page.h +++ b/arch/x86/include/asm/page.h @@ -7,6 +7,7 @@ #ifdef __KERNEL__ =20 #include +#include =20 #ifdef CONFIG_X86_64 #include @@ -65,6 +66,13 @@ static inline void copy_user_page(void *to, void *from, = unsigned long vaddr, * virt_to_page(kaddr) returns a valid pointer if and only if * virt_addr_valid(kaddr) returns true. */ + +#ifdef CONFIG_KASAN_SW_TAGS +#define page_to_virt(x) ({ \ + void *__addr =3D __va(page_to_pfn((struct page *)x) << PAGE_SHIFT); \ + __tag_set(__addr, page_kasan_tag(x)); \ +}) +#endif #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT) extern bool __virt_addr_valid(unsigned long kaddr); #define virt_addr_valid(kaddr) __virt_addr_valid((unsigned long) (kaddr)) diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h index 015d23f3e01f..b18fef43dd34 100644 --- a/arch/x86/include/asm/page_64.h +++ b/arch/x86/include/asm/page_64.h @@ -21,6 +21,7 @@ extern unsigned long direct_map_physmem_end; =20 static __always_inline unsigned long __phys_addr_nodebug(unsigned long x) { + x =3D __tag_reset(x); unsigned long y =3D x - __START_KERNEL_map; =20 /* use the carry flag to determine if x was < __START_KERNEL_map */ diff --git a/arch/x86/mm/physaddr.c b/arch/x86/mm/physaddr.c index fc3f3d3e2ef2..d6aa3589c798 100644 --- a/arch/x86/mm/physaddr.c +++ b/arch/x86/mm/physaddr.c @@ -14,6 +14,7 @@ #ifdef CONFIG_DEBUG_VIRTUAL unsigned long __phys_addr(unsigned long x) { + x =3D __tag_reset(x); unsigned long y =3D x - __START_KERNEL_map; =20 /* use the carry flag to determine if x was < __START_KERNEL_map */ @@ -46,6 +47,7 @@ EXPORT_SYMBOL(__phys_addr_symbol); =20 bool __virt_addr_valid(unsigned long x) { + x =3D __tag_reset(x); unsigned long y =3D x - __START_KERNEL_map; =20 /* use the carry flag to determine if x was < __START_KERNEL_map */ --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch [109.224.244.18]) (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 9173B3596E5 for ; Wed, 29 Oct 2025 19:08:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764883; cv=none; b=oDLBmGwRuuuEVcWXCguCQxei7QMs7h3DPA9zKe6XlrQJ1N1j/fldPWNQLBXqVHqtEPioDP866z4f0lKFlzLkS67TBeDfTOhLz/v13lVvprU8VuUSQogQ4KJuABqAhqDsiaq69XeeFvBEHPD4uB4PXbbA3OQOqLbLghurTHtTIQA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761764883; c=relaxed/simple; bh=+Go/spjpR5TeE/IjzS8oR2CgyekBuI39XLFNABje2C0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NRv5gX1fIMeDlzucwTXy7qtIZbuyn2fZCOfMIO8oBsn/7aWa+7A2/ORdcyfRfjFWCVoBrPdpDfG6NyJ4n8rhmToKUgFmqavdrWDSJLpzRTcRoEuC/iAkIRdcgagpR2hFzupsj6T0YYuWCASpCF4zACF3l2WrIz3g+HSKgc+/tzg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=IJcPNw3y; arc=none smtp.client-ip=109.224.244.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="IJcPNw3y" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761764878; x=1762024078; bh=wC6RWC0BysYEjK4tLyl5sRrziRZnxpuWzjQ8a6tBeM4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=IJcPNw3yh2TNHyjZf2+7PCXVO4q2xt+d6RxGzTh3Nu9x6lPPz5KLDRfUUfHQdlsKV wpWXVbuGFSvXG6l3dJVLam23As54rJ+3MbI3AG03fI4SYHJDfUZql6kA9SeuWdefRC 5+jMHJpl7Ynw68PwkNnrvsAcORWvFbm1k8DSjDHbQ+xpmJaeKE1oSCduAyYgtUMcxp 5c/Y6liDXu9mw7a4gi1lz/+DQQLpT0qHscmGiFFf4YATArppuRqPL0lVDXIuQMCAOk bN6yhswOyjHR0i79XSrB7Y/Xm+Xr4dmniCQDAvXrEx+6zarj5Hj/TzoELeXGT328Cw zjj5lDm5ggAKQ== Date: Wed, 29 Oct 2025 19:07:50 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 09/18] mm/execmem: Untag addresses in EXECMEM_ROX related pointer arithmetic Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 63b0d2f639705dfa0c06cb457ca2d9660abebfed Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman ARCH_HAS_EXECMEM_ROX was re-enabled in x86 at Linux 6.14 release. vm_reset_perms() calculates range's start and end addresses using min() and max() functions. To do that it compares pointers but, with KASAN software tags mode enabled, some are tagged - addr variable is, while start and end variables aren't. This can cause the wrong address to be chosen and result in various errors in different places. Reset tags in the address used as function argument in min(), max(). execmem_cache_add() adds tagged pointers to a maple tree structure, which then are incorrectly compared when walking the tree. That results in different pointers being returned later and page permission violation errors panicking the kernel. Reset tag of the address range inserted into the maple tree inside execmem_vmalloc() which then gets propagated to execmem_cache_add(). Signed-off-by: Maciej Wieczor-Retman Acked-by: Alexander Potapenko --- Changelog v6: - Move back the tag reset from execmem_cache_add() to execmem_vmalloc() (Mike Rapoport) - Rewrite the changelogs to match the code changes from v6 and v5. Changelog v5: - Remove the within_range() change. - arch_kasan_reset_tag -> kasan_reset_tag. Changelog v4: - Add patch to the series. mm/execmem.c | 2 +- mm/vmalloc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/execmem.c b/mm/execmem.c index 810a4ba9c924..fd11409a6217 100644 --- a/mm/execmem.c +++ b/mm/execmem.c @@ -59,7 +59,7 @@ static void *execmem_vmalloc(struct execmem_range *range,= size_t size, return NULL; } =20 - return p; + return kasan_reset_tag(p); } =20 struct vm_struct *execmem_vmap(size_t size) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 934c8bfbcebf..392e3863d7d0 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3328,7 +3328,7 @@ static void vm_reset_perms(struct vm_struct *area) * the vm_unmap_aliases() flush includes the direct map. */ for (i =3D 0; i < area->nr_pages; i +=3D 1U << page_order) { - unsigned long addr =3D (unsigned long)page_address(area->pages[i]); + unsigned long addr =3D (unsigned long)kasan_reset_tag(page_address(area-= >pages[i])); =20 if (addr) { unsigned long page_size; --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) (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 936A431A7F1 for ; Wed, 29 Oct 2025 20:07:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.43.22 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768434; cv=none; b=ulBeTewnvCU9CGsBK545TdzyZ6ltRVchLAdvcO7DMWCEChedyDZd2jpU9iZsIjbPlyFDCXZgBPeBSb2zH1ey2jPH+3/NYVyNqmRcbqrLfUqCoJFrBazmfQBqn+evK5rjcIG05hC7gbwIVcBwnTm55QDDjn6iN4zGyoma/0laCxA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768434; c=relaxed/simple; bh=+cA2njdiqaGsLKzMeaYLJnV2PWefw9DHpnKbgEVAOp8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=E5z4BMLu/bV++yM5S1pAh70Sbjo38AAZA8T3KCOK1PIq9FhAW8IBA0hGIhYPnq9/Nm6CG4nNv0F8Lngy7oUqa9huCib8nnpBAel7VgS+YC4XuY7swaHBVDpo1FVFZQfIgzXv7wBfzca2JqUg4BIyaPJTyJ3M6hsUkwzjdmYGCKE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=Q8fbvGeL; arc=none smtp.client-ip=185.70.43.22 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="Q8fbvGeL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761768428; x=1762027628; bh=ORgS5h+xBvFClF5iXcyTXC092gY8CGZFTCYy/D6hFpU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Q8fbvGeL2ExKLfg1F1thHnRQ92jM0SfvidRW/4ypa4lolos8RCX0lLu+i2H6kTK6S MaA1nBDNDQPyyfdcKvl+1OcEfLMV2Viqk9a+x2KT3lXIr9hXFR4fmSs0XylD1sTGie tsO96krT1yWQpKu1JBZ1xoqT/Am1AJerQd1O8H4fUA92e+JgBxhZqZgpSkBFj0QbBY kK5jeFm7SA2QiUwxKEOqXSEioeBK0pAcc9z8/Bx7JbdabNmBwQBKWD9VAd4AMK2nqH tn//iBIEYCz7O+2enlz2b7WX/VCaIyvT/kkUpw3q6WdAghPk/Ks4hSNUdaZmzn+OT9 2SUvjbSgsrkKQ== Date: Wed, 29 Oct 2025 20:07:02 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 10/18] x86/mm: Physical address comparisons in fill_p*d/pte Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 931b8bb7920f3633ea9d19d797d43379e99d4838 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman Calculating page offset returns a pointer without a tag. When comparing the calculated offset to a tagged page pointer an error is raised because they are not equal. Change pointer comparisons to physical address comparisons as to avoid issues with tagged pointers that pointer arithmetic would create. Open code pte_offset_kernel(), pmd_offset(), pud_offset() and p4d_offset(). Because one parameter is always zero and the rest of the function insides are enclosed inside __va(), removing that layer lowers the complexity of final assembly. Signed-off-by: Maciej Wieczor-Retman --- Changelog v2: - Open code *_offset() to avoid it's internal __va(). arch/x86/mm/init_64.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index 0e4270e20fad..2d79fc0cf391 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -269,7 +269,10 @@ static p4d_t *fill_p4d(pgd_t *pgd, unsigned long vaddr) if (pgd_none(*pgd)) { p4d_t *p4d =3D (p4d_t *)spp_getpage(); pgd_populate(&init_mm, pgd, p4d); - if (p4d !=3D p4d_offset(pgd, 0)) + + if (__pa(p4d) !=3D (pgtable_l5_enabled() ? + __pa(pgd) : + (unsigned long)pgd_val(*pgd) & PTE_PFN_MASK)) printk(KERN_ERR "PAGETABLE BUG #00! %p <-> %p\n", p4d, p4d_offset(pgd, 0)); } @@ -281,7 +284,7 @@ static pud_t *fill_pud(p4d_t *p4d, unsigned long vaddr) if (p4d_none(*p4d)) { pud_t *pud =3D (pud_t *)spp_getpage(); p4d_populate(&init_mm, p4d, pud); - if (pud !=3D pud_offset(p4d, 0)) + if (__pa(pud) !=3D (p4d_val(*p4d) & p4d_pfn_mask(*p4d))) printk(KERN_ERR "PAGETABLE BUG #01! %p <-> %p\n", pud, pud_offset(p4d, 0)); } @@ -293,7 +296,7 @@ static pmd_t *fill_pmd(pud_t *pud, unsigned long vaddr) if (pud_none(*pud)) { pmd_t *pmd =3D (pmd_t *) spp_getpage(); pud_populate(&init_mm, pud, pmd); - if (pmd !=3D pmd_offset(pud, 0)) + if (__pa(pmd) !=3D (pud_val(*pud) & pud_pfn_mask(*pud))) printk(KERN_ERR "PAGETABLE BUG #02! %p <-> %p\n", pmd, pmd_offset(pud, 0)); } @@ -305,7 +308,7 @@ static pte_t *fill_pte(pmd_t *pmd, unsigned long vaddr) if (pmd_none(*pmd)) { pte_t *pte =3D (pte_t *) spp_getpage(); pmd_populate_kernel(&init_mm, pmd, pte); - if (pte !=3D pte_offset_kernel(pmd, 0)) + if (__pa(pte) !=3D (pmd_val(*pmd) & pmd_pfn_mask(*pmd))) printk(KERN_ERR "PAGETABLE BUG #03!\n"); } return pte_offset_kernel(pmd, vaddr); --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch [109.224.244.17]) (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 6CAE931A805; Wed, 29 Oct 2025 20:07:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768470; cv=none; b=qvRuPQXDuI0zqR4qOC4nchwnuVa56na1lz6DB3cUFuleQgU+vbnc2ovFTQU2iUuZf5B3aU04PpQMlmxU8Fr7L6wUsW6wyML287SbDSwtoUEkgSS1S8jpmTr2m7GDVygV/KoG1j+HXs0PxvNvhuApYrZdqdVixhjtSsHFJXybJTs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768470; c=relaxed/simple; bh=pG6PmCayk69IIjMpN+E9J4X5ppcFU9gBb5y0rPTdVEE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WCeOLXtUveypGp+U+RK3PoKigwLTRyW7oazbA5SKaRqVlpsnRyqh4LycjlGUBt+4j1BlFUnuimtvhbAQa3BPHdkqIypsfsOXAAwdsXq22+fKTUxMjE1fpPRcQMtwUXZlnZbdh73Ig4up4kZe4PdvtistQVpF9cY0MHADrEGVTEk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=bjmx3g8O; arc=none smtp.client-ip=109.224.244.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="bjmx3g8O" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761768465; x=1762027665; bh=h7bOmcRxuqO6z3MZPe9zBvs6V2vz8fOGqA1RpHhG/FE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=bjmx3g8OlacQX7FEB7CB4gFpPcUTD0I5Kc1p43/y9uXqIMVnKJWIWOuru2SF/QQfu 6AiAPDukFzXStuxWTR5WDI0wUwQ3jAjKxjVKN/rW5W4cFnmYpLhh/SnXC+CNzfiPNN yCU0Y0WKKnfImz6JKMr3Dj0qQjo+Mp/U3OEVrV6kaX0VUG3dIxPsjjzPd48CTfn+MD HpUu7+z+rhYq8apG5mFFr/w3+YtjPLc59AwJlIe7QmemdTNU+aT/cA3JtTnT2ge0If nWKsUZ1l87vhw5I/ZZHp5y2xOcPYMO6CexFWC9kS9HmKpnu1vWPf8OvbB4AV2iSubm Hlcw1buJNqcCg== Date: Wed, 29 Oct 2025 20:07:38 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 11/18] x86/kasan: KASAN raw shadow memory PTE init Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 388931058df330f6e092950b7ef3ba7585e70752 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman In KASAN's generic mode the default value in shadow memory is zero. During initialization of shadow memory pages they are allocated and zeroed. In KASAN's tag-based mode the default tag for the arm64 architecture is 0xFE which corresponds to any memory that should not be accessed. On x86 (where tags are 4-bit wide instead of 8-bit wide) that tag is 0xE so during the initializations all the bytes in shadow memory pages should be filled with it. Use memblock_alloc_try_nid_raw() instead of memblock_alloc_try_nid() to avoid zeroing out the memory so it can be set with the KASAN invalid tag. Signed-off-by: Maciej Wieczor-Retman Reviewed-by: Alexander Potapenko --- Changelog v2: - Remove dense mode references, use memset() instead of kasan_poison(). arch/x86/mm/kasan_init_64.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c index 998b6010d6d3..e69b7210aaae 100644 --- a/arch/x86/mm/kasan_init_64.c +++ b/arch/x86/mm/kasan_init_64.c @@ -34,6 +34,18 @@ static __init void *early_alloc(size_t size, int nid, bo= ol should_panic) return ptr; } =20 +static __init void *early_raw_alloc(size_t size, int nid, bool should_pani= c) +{ + void *ptr =3D memblock_alloc_try_nid_raw(size, size, + __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, nid); + + if (!ptr && should_panic) + panic("%pS: Failed to allocate page, nid=3D%d from=3D%lx\n", + (void *)_RET_IP_, nid, __pa(MAX_DMA_ADDRESS)); + + return ptr; +} + static void __init kasan_populate_pmd(pmd_t *pmd, unsigned long addr, unsigned long end, int nid) { @@ -63,8 +75,9 @@ static void __init kasan_populate_pmd(pmd_t *pmd, unsigne= d long addr, if (!pte_none(*pte)) continue; =20 - p =3D early_alloc(PAGE_SIZE, nid, true); - entry =3D pfn_pte(PFN_DOWN(__pa(p)), PAGE_KERNEL); + p =3D early_raw_alloc(PAGE_SIZE, nid, true); + memset(p, PAGE_SIZE, KASAN_SHADOW_INIT); + entry =3D pfn_pte(PFN_DOWN(__pa_nodebug(p)), PAGE_KERNEL); set_pte_at(&init_mm, addr, pte, entry); } while (pte++, addr +=3D PAGE_SIZE, addr !=3D end); } @@ -436,7 +449,7 @@ void __init kasan_init(void) * it may contain some garbage. Now we can clear and write protect it, * since after the TLB flush no one should write to it. */ - memset(kasan_early_shadow_page, 0, PAGE_SIZE); + memset(kasan_early_shadow_page, KASAN_SHADOW_INIT, PAGE_SIZE); for (i =3D 0; i < PTRS_PER_PTE; i++) { pte_t pte; pgprot_t prot; --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (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 002672DE200; Wed, 29 Oct 2025 20:08:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.43.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768510; cv=none; b=UnF595ze7gK0D4C29Pu8FgA2E7Z+Jq4+IugtBdQX2L5yABysCu8mmQo3XEMeiqmz3XiwCcU144U/WBTluB5VltsI2GjP9bEfj0pMLp446Ey9gBlzLW2gRsKY6v4Bcgxib2Tz3mCZJR9JlGQ5xdVCr+Fl5uHSrcLtQgXws4j60mA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768510; c=relaxed/simple; bh=bVzjv4HTOC1vQrn+XBZNIMKDdCF53/G6D7SEjdZ3RUs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=hcit+rYC99+bE8NiHAzuv7OEVhs4XYGCmtwpOIqjgXfYvIgsBPD9mfScUaCnT+3tyaWFUgfbVHIC/6lD8NAk4v4Q4ZGZgJr32ksf8N1nsMLJ8pqEUgiNqOZQA3xYFEfB22A01fLtMMOB8ABY6Ex72oBof9cY3tVE492o+6SRFQU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=f1ahGvJ8; arc=none smtp.client-ip=185.70.43.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="f1ahGvJ8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761768504; x=1762027704; bh=Ye8tYnzEiAyAJOizOqIrcZYSk2K1DbVUwkfvl955amo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=f1ahGvJ8GYmWSAN4yQvaJJ8AMmaQXPPMzcKSaz6Xrvq0aoFjM/UK6qEVGIKRCoLqb 5LIptGgTqr85HdCtdsCnnkULneMU0vlAU6dQciyV6UUzUvyMy/kCVMmX+/4xr6YHW/ +oMozIC9BWSxBmEgcmmyjZZG3vnN+B3w2jxVYTdAYKkzhqe2taxX2Pl6kthj9hres/ YBb4kjMyUMhTGxyvSz8vda/30rOZZimxFRxQD0jyouhiV9xwy9nfBkUN6uEXRd/Z/X euFq5/cNqoY3dnXuBokf29Dwc8D5+0mx1I6WMSm4ouiysMLrt2mGdvalln0qeq9P+o sDufRjOTA1fvw== Date: Wed, 29 Oct 2025 20:08:18 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 12/18] x86/mm: LAM compatible non-canonical definition Message-ID: <56d9203b1fcb6281b0d29b44bc181530e5c72327.1761763681.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 015c7fdaea374a790951b755b565538ef4bdd04b Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman For an address to be canonical it has to have its top bits equal to each other. The number of bits depends on the paging level and whether they're supposed to be ones or zeroes depends on whether the address points to kernel or user space. With Linear Address Masking (LAM) enabled, the definition of linear address canonicality is modified. Not all of the previously required bits need to be equal, only the first and last from the previously equal bitmask. So for example a 5-level paging kernel address needs to have bits [63] and [56] set. Change the canonical checking function to use bit masks instead of bit shifts. Signed-off-by: Maciej Wieczor-Retman Acked-by: Alexander Potapenko --- Changelog v6: - Use bitmasks to check both kernel and userspace addresses (Dave Hansen and Samuel Holland). Changelog v4: - Add patch to the series. arch/x86/include/asm/page.h | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h index bcf5cad3da36..df2c93b90a6b 100644 --- a/arch/x86/include/asm/page.h +++ b/arch/x86/include/asm/page.h @@ -82,14 +82,37 @@ static __always_inline void *pfn_to_kaddr(unsigned long= pfn) return __va(pfn << PAGE_SHIFT); } =20 +/* + * CONFIG_KASAN_SW_TAGS requires LAM which changes the canonicality checks. + */ +#ifdef CONFIG_KASAN_SW_TAGS +static __always_inline u64 __canonical_address(u64 vaddr, u8 vaddr_bits) +{ + return (vaddr | BIT_ULL(63) | BIT_ULL(vaddr_bits - 1)); +} +#else static __always_inline u64 __canonical_address(u64 vaddr, u8 vaddr_bits) { return ((s64)vaddr << (64 - vaddr_bits)) >> (64 - vaddr_bits); } +#endif + +#ifdef CONFIG_KASAN_SW_TAGS +#define CANONICAL_MASK(vaddr_bits) (BIT_ULL(63) | BIT_ULL(vaddr_bits - 1)) +#else +#define CANONICAL_MASK(vaddr_bits) GENMASK_ULL(63, vaddr_bits) +#endif =20 static __always_inline u64 __is_canonical_address(u64 vaddr, u8 vaddr_bits) { - return __canonical_address(vaddr, vaddr_bits) =3D=3D vaddr; + unsigned long cmask =3D CANONICAL_MASK(vaddr_bits); + + /* + * Kernel canonical address & cmask will evaluate to cmask while + * userspace canonical address & cmask will evaluate to zero. + */ + u64 result =3D (vaddr & cmask) =3D=3D cmask || !(vaddr & cmask); + return result; } =20 #endif /* __ASSEMBLER__ */ --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch [109.224.244.16]) (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 18C8127A462; Wed, 29 Oct 2025 20:08:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768539; cv=none; b=bbmJ1inlZk6vNAe3nBIU+tXCXKGey3qfwVTp8m6gGSaqYPdX+oWyDGlgL/ikoV72XYKcqtqwwr4slLKy51bwJKv6Btsa6NxWrNNNJxzwnrAjSZNLoaATbHy7WWRIDmJrCqXYvWVgdV+6+Jz2ry5Fqj2PafUmRsVD6iHwlB47jxQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768539; c=relaxed/simple; bh=Ih8wwv/hVIpNDdvgfkJCAuMYW2YA73jRDPxtzkA+aI4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VnvApwsTb/hrO6uZQMILsC20VnoECAimDIrP96qMvtNiMVtQQivRTW7uTsZ5Fi1LhrvIVzb32eBXHItDIl2eZkYMeJdXrnxtoy5b9PGOhECpsKXMm4N/rjeBkh37gFrXMYOdokclEYkB19GQM6cmdzDH+WxHyyGnKQUuq12IKQM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=f2ixPvRO; arc=none smtp.client-ip=109.224.244.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="f2ixPvRO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761768530; x=1762027730; bh=+vFEd2i7cGwKfB76083zqMnaJRzsau0IVtzvsF2hHkA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=f2ixPvROXBBe3oYcnt46ZpuoD3whpqDkx+uWuzdhIU+YPbduMbbLBUYy3V19N8DdT lJCQaItYc4V04frYC10Qp8vC4v6QealyZOWFQ9x+4qrE9lklIogwUqZ4H130zyymmQ QuU0Jp39WS7X0fe1Z0N55I/Nb2bcW5EMWiLI8MAIscT6weHJpTE4qsZY5FWESEyQBa XhAFbluJjDjJ4OVPWlAMCFRWCe1eIQ5pzDu9nHbw1L5wWjcHpVsCvn8VHSo6rvjAi8 DZuZbhfARnsZ1Xh2scxFMiBarfrU81v14JAR7983upQVZyAIOMSBej2abjtKpLwF5M HwEJuccHvAyqQ== Date: Wed, 29 Oct 2025 20:08:43 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 13/18] x86/mm: LAM initialization Message-ID: <96559d5a8e897f97879259bad3117db617e21377.1761763681.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 0e1842514ef97eaa33355f60d534577848d5c6b8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman To make use of KASAN's tag based mode on x86, Linear Address Masking (LAM) needs to be enabled. To do that the 28th bit in CR4 has to be set. Set the bit in early memory initialization. When launching secondary CPUs the LAM bit gets lost. To avoid this add it in a mask in head_64.S. The bitmask permits some bits of CR4 to pass from the primary CPU to the secondary CPUs without being cleared. Signed-off-by: Maciej Wieczor-Retman Acked-by: Alexander Potapenko --- Changelog v6: - boot_cpu_has() -> cpu_feature_enabled() arch/x86/kernel/head_64.S | 3 +++ arch/x86/mm/init.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index 21816b48537c..c5a0bfbe280d 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -209,6 +209,9 @@ SYM_INNER_LABEL(common_startup_64, SYM_L_LOCAL) * there will be no global TLB entries after the execution." */ movl $(X86_CR4_PAE | X86_CR4_LA57), %edx +#ifdef CONFIG_ADDRESS_MASKING + orl $X86_CR4_LAM_SUP, %edx +#endif #ifdef CONFIG_X86_MCE /* * Preserve CR4.MCE if the kernel will enable #MC support. diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index 8bf6ad4b9400..a8442b255481 100644 --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -764,6 +764,9 @@ void __init init_mem_mapping(void) probe_page_size_mask(); setup_pcid(); =20 + if (cpu_feature_enabled(X86_FEATURE_LAM) && IS_ENABLED(CONFIG_KASAN_SW_TA= GS)) + cr4_set_bits_and_update_boot(X86_CR4_LAM_SUP); + #ifdef CONFIG_X86_64 end =3D max_pfn << PAGE_SHIFT; #else --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) (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 E965B311C3C for ; Wed, 29 Oct 2025 20:09:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.43.22 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768579; cv=none; b=lxpAkMLmRJg48ln9ZGx0NmSZKquaXGyUiJ60d1NyZw0yWHpHrBzhgJ7jWqjx5rtpukecIhLeo2hCytkhg1WOmXFwO22gp2WcNRc+o0M+dPxq1se/a2z2VyH1J9N3RzztnzWx6LZ4dvf3qUIP6YUNYlfrV5G6Ti5IqDEvgrTnKGU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768579; c=relaxed/simple; bh=aq/YLoHo9/4ylK4DNJ/Ooj2NvFqNsQUxDxnPGzRn87c=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=r/okEXvhhPtZr4v4uR7W6J/QRgxZhyb51z6txyE0jeWLVUQvSxWvQ89wj7g67aDHhLuuRd47aYm/KWMRPLpEBURE56Tpd6rqd3oG3fMWrINayPk81BLrHlwUgkpBm/FpzqrxPB524kjcCuhA0SO2ufXm97zqiWlwqE+EpEscLzo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=GiO+NP1C; arc=none smtp.client-ip=185.70.43.22 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="GiO+NP1C" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761768575; x=1762027775; bh=9kO+NK4R04JM70PmVsjA3ThrFoFrY2dEYZyEQtxD9Gc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=GiO+NP1Cl8/oha+EezztD/oioG80KLBwC09Ce0/RmuvQMCBBOpsvpeyrM1SYKP380 L55FlMbYoS9vvMYp6u+V/7HJh5NlPM25E3S/mc7Yo6015R0C0GV6qsbAZ0uhT1F7A0 mpcNgf97G1MEObQ5l3M7Y1fy71MJY1hXHoqBjAcP6kuvTg7wW06FUUqhHu+0cQ9ob4 74pYfXnPEt5uOz28lW7xSav9FPCJaxYHlp/8fDhgCMIbN9UWvw5d+D8fOPV6TBll7J Dzv2hAiwmoltCsMMbtVmhyUxeYuIifVpZya2+ANHr1l0hRf1ny1I1hgtqU13yTLAP8 uD8Rn3tilxeaA== Date: Wed, 29 Oct 2025 20:09:28 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 14/18] x86: Minimal SLAB alignment Message-ID: <0ca5d46e292e5074c119c7c58e6ec9901fb0ed73.1761763681.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: bb212e55891aa41be391c49c804782cab1b9ead2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman 8 byte minimal SLAB alignment interferes with KASAN's granularity of 16 bytes. It causes a lot of out-of-bounds errors for unaligned 8 byte allocations. Compared to a kernel with KASAN disabled, the memory footprint increases because all kmalloc-8 allocations now are realized as kmalloc-16, which has twice the object size. But more meaningfully, when compared to a kernel with generic KASAN enabled, there is no difference. Because of redzones in generic KASAN, kmalloc-8' and kmalloc-16' object size is the same (48 bytes). So changing the minimal SLAB alignment of the tag-based mode doesn't have any negative impact when compared to the other software KASAN mode. Adjust x86 minimal SLAB alignment to match KASAN granularity size. Signed-off-by: Maciej Wieczor-Retman Reviewed-by: Andrey Konovalov --- Changelog v6: - Add Andrey's Reviewed-by tag. Changelog v4: - Extend the patch message with some more context and impact information. Changelog v3: - Fix typo in patch message 4 -> 16. - Change define location to arch/x86/include/asm/cache.c. arch/x86/include/asm/cache.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/include/asm/cache.h b/arch/x86/include/asm/cache.h index 69404eae9983..3232583b5487 100644 --- a/arch/x86/include/asm/cache.h +++ b/arch/x86/include/asm/cache.h @@ -21,4 +21,8 @@ #endif #endif =20 +#ifdef CONFIG_KASAN_SW_TAGS +#define ARCH_SLAB_MINALIGN (1ULL << KASAN_SHADOW_SCALE_SHIFT) +#endif + #endif /* _ASM_X86_CACHE_H */ --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch [79.135.106.29]) (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 E86BF3502AD for ; Wed, 29 Oct 2025 20:10:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.29 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768603; cv=none; b=QPXIxiEqwIGfkCDi+RzLfkrD4bPRrw9Ynt8k1nb8ugXSac4LgiD688lG9SPhGu7Q1fejeu3K6nw4iGvQitFfy8HaGeygaji8oFITOSo15l7/8GMzTyYAB/w5KVT01Q+b0bF12Xn6irgOyBZPFi8kcaq9p549JoH4oKsJ16APOJ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768603; c=relaxed/simple; bh=jEmJKiDGaKr1Ozen4a1EogitDsnx48GxuX85uDh3IVc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=okmjlKhNSgArbpfDrQocWKsBLZ6H/ZQ/37WQGynLpVHo8q4ux1ipd0gEfzEHzUU++vuvQ5hNQHOqESM8CWS+PLA2/xC20zxPxZg3+kwCf19uV0bbBrHv4O27hFFImgYPdvBvJHO0+s63v7kWOTHv9tV6AUKeaZg4N+f33wTGIRA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=pBdq+49r; arc=none smtp.client-ip=79.135.106.29 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="pBdq+49r" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761768596; x=1762027796; bh=IfDaBLNxvsgHIrxT5fF1MIs0svV8id6MA4rHYub5Mv4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=pBdq+49rTHNOBK233h+hE/8kgDm119V2Cyxh6x3CJfUMZgrImJKljJzkL1rJ7FpqB oGMZ1cBZqpXVXJeKUzdFZqImw5pwDEW+1z5wCJPnEHS7j4lEg1vdCjyI/cvYqUJuMo 9T8x43dN+CeMwlYtpVk04VWb2INWjgDZeF+hJggjQ/XfdfovcfacS5HJQor96976tN zvdFuxv3E95MUK8nGO6R/5N7r2oC8TGp5QLzX5KaAhpJPaYXTlr0MKSh/ikIdguoT/ L/3HACO477GDPSw6c54QqDArd+BB1hZxgTw0xETeO0yJRwxcwh9nAkRfr621JKAlIN 2B4VfucEgl9IQ== Date: Wed, 29 Oct 2025 20:09:51 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 15/18] x86/kasan: Handle UD1 for inline KASAN reports Message-ID: <8b0daaf83752528418bf2dd8d08906c37fa31f69.1761763681.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: db233bf96a7423ff32d19231938d1a80a3e5afe6 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman Inline KASAN on x86 should do tag mismatch reports by passing the metadata through the UD1 instruction and the faulty address through RDI, a scheme that's already used by UBSan and is easy to extend. The current LLVM way of passing KASAN software tag mode metadata is done using the INT3 instruction. However that should be changed because it doesn't align to how the kernel already handles UD1 for similar use cases. Since inline software tag-based KASAN doesn't work on x86 due to missing compiler support it can be fixed and the INT3 can be changed to UD1 at the same time. Add a kasan component to the #UD decoding and handling functions. Make part of that hook - which decides whether to die or recover from a tag mismatch - arch independent to avoid duplicating a long comment on both x86 and arm64 architectures. Signed-off-by: Maciej Wieczor-Retman --- Changelog v6: - Change the whole patch from using INT3 to UD1. Changelog v5: - Add die to argument list of kasan_inline_recover() in arch/arm64/kernel/traps.c. Changelog v4: - Make kasan_handler() a stub in a header file. Remove #ifdef from traps.c. - Consolidate the "recover" comment into one place. - Make small changes to the patch message. MAINTAINERS | 2 +- arch/x86/include/asm/bug.h | 1 + arch/x86/include/asm/kasan.h | 20 ++++++++++++++++++++ arch/x86/kernel/traps.c | 8 ++++++++ arch/x86/mm/Makefile | 2 ++ arch/x86/mm/kasan_inline.c | 21 +++++++++++++++++++++ include/linux/kasan.h | 23 +++++++++++++++++++++++ 7 files changed, 76 insertions(+), 1 deletion(-) create mode 100644 arch/x86/mm/kasan_inline.c diff --git a/MAINTAINERS b/MAINTAINERS index 53cbc7534911..a6e3cc2f3cc5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13422,7 +13422,7 @@ S: Maintained B: https://bugzilla.kernel.org/buglist.cgi?component=3DSanitizers&product= =3DMemory%20Management F: Documentation/dev-tools/kasan.rst F: arch/*/include/asm/*kasan*.h -F: arch/*/mm/kasan_init* +F: arch/*/mm/kasan_* F: include/linux/kasan*.h F: lib/Kconfig.kasan F: mm/kasan/ diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h index 880ca15073ed..428c8865b995 100644 --- a/arch/x86/include/asm/bug.h +++ b/arch/x86/include/asm/bug.h @@ -31,6 +31,7 @@ #define BUG_UD2 0xfffe #define BUG_UD1 0xfffd #define BUG_UD1_UBSAN 0xfffc +#define BUG_UD1_KASAN 0xfffb #define BUG_UDB 0xffd6 #define BUG_LOCK 0xfff0 =20 diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h index 396071832d02..375651d9b114 100644 --- a/arch/x86/include/asm/kasan.h +++ b/arch/x86/include/asm/kasan.h @@ -6,6 +6,24 @@ #include #include #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL) + +/* + * LLVM ABI for reporting tag mismatches in inline KASAN mode. + * On x86 the UD1 instruction is used to carry metadata in the ECX register + * to the KASAN report. ECX is used to differentiate KASAN from UBSan when + * decoding the UD1 instruction. + * + * SIZE refers to how many bytes the faulty memory access + * requested. + * WRITE bit, when set, indicates the access was a write, otherwise + * it was a read. + * RECOVER bit, when set, should allow the kernel to carry on after + * a tag mismatch. Otherwise die() is called. + */ +#define KASAN_ECX_RECOVER 0x20 +#define KASAN_ECX_WRITE 0x10 +#define KASAN_ECX_SIZE_MASK 0x0f +#define KASAN_ECX_SIZE(ecx) (1 << ((ecx) & KASAN_ECX_SIZE_MASK)) #define KASAN_SHADOW_SCALE_SHIFT 3 =20 /* @@ -34,10 +52,12 @@ #define __tag_shifted(tag) FIELD_PREP(GENMASK_ULL(60, 57), tag) #define __tag_reset(addr) (sign_extend64((u64)(addr), 56)) #define __tag_get(addr) ((u8)FIELD_GET(GENMASK_ULL(60, 57), (u64)addr)) +void kasan_inline_handler(struct pt_regs *regs); #else #define __tag_shifted(tag) 0UL #define __tag_reset(addr) (addr) #define __tag_get(addr) 0 +static inline void kasan_inline_handler(struct pt_regs *regs) { } #endif /* CONFIG_KASAN_SW_TAGS */ =20 #ifdef CONFIG_64BIT diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 6b22611e69cc..40fefd306c76 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -179,6 +179,9 @@ __always_inline int decode_bug(unsigned long addr, s32 = *imm, int *len) if (X86_MODRM_REG(v) =3D=3D 0) /* EAX */ return BUG_UD1_UBSAN; =20 + if (X86_MODRM_REG(v) =3D=3D 1) /* ECX */ + return BUG_UD1_KASAN; + return BUG_UD1; } =20 @@ -357,6 +360,11 @@ static noinstr bool handle_bug(struct pt_regs *regs) } break; =20 + case BUG_UD1_KASAN: + kasan_inline_handler(regs); + handled =3D true; + break; + default: break; } diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index 5b9908f13dcf..1dc18090cbe7 100644 --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -36,7 +36,9 @@ obj-$(CONFIG_PTDUMP) +=3D dump_pagetables.o obj-$(CONFIG_PTDUMP_DEBUGFS) +=3D debug_pagetables.o =20 KASAN_SANITIZE_kasan_init_$(BITS).o :=3D n +KASAN_SANITIZE_kasan_inline.o :=3D n obj-$(CONFIG_KASAN) +=3D kasan_init_$(BITS).o +obj-$(CONFIG_KASAN_SW_TAGS) +=3D kasan_inline.o =20 KMSAN_SANITIZE_kmsan_shadow.o :=3D n obj-$(CONFIG_KMSAN) +=3D kmsan_shadow.o diff --git a/arch/x86/mm/kasan_inline.c b/arch/x86/mm/kasan_inline.c new file mode 100644 index 000000000000..65641557c294 --- /dev/null +++ b/arch/x86/mm/kasan_inline.c @@ -0,0 +1,21 @@ +// SPDX-License-Identifier: GPL-2.0 +#include +#include + +void kasan_inline_handler(struct pt_regs *regs) +{ + int metadata =3D regs->cx; + u64 addr =3D regs->di; + u64 pc =3D regs->ip; + bool recover =3D metadata & KASAN_ECX_RECOVER; + bool write =3D metadata & KASAN_ECX_WRITE; + size_t size =3D KASAN_ECX_SIZE(metadata); + + if (user_mode(regs)) + return; + + if (!kasan_report((void *)addr, size, write, pc)) + return; + + kasan_die_unless_recover(recover, "Oops - KASAN", regs, metadata, die); +} diff --git a/include/linux/kasan.h b/include/linux/kasan.h index 3c0c60ed5d5c..9bd1b1ebd674 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -679,4 +679,27 @@ void kasan_non_canonical_hook(unsigned long addr); static inline void kasan_non_canonical_hook(unsigned long addr) { } #endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */ =20 +#ifdef CONFIG_KASAN_SW_TAGS +/* + * The instrumentation allows to control whether we can proceed after + * a crash was detected. This is done by passing the -recover flag to + * the compiler. Disabling recovery allows to generate more compact + * code. + * + * Unfortunately disabling recovery doesn't work for the kernel right + * now. KASAN reporting is disabled in some contexts (for example when + * the allocator accesses slab object metadata; this is controlled by + * current->kasan_depth). All these accesses are detected by the tool, + * even though the reports for them are not printed. + * + * This is something that might be fixed at some point in the future. + */ +static inline void kasan_die_unless_recover(bool recover, char *msg, struc= t pt_regs *regs, + unsigned long err, void die_fn(const char *str, struct pt_regs *regs, lon= g err)) +{ + if (!recover) + die_fn(msg, regs, err); +} +#endif + #endif /* LINUX_KASAN_H */ --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch [109.224.244.18]) (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 B26F635A922 for ; Wed, 29 Oct 2025 20:10:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768638; cv=none; b=IZEHdqgMO8RO+Vk2RBdHSrH8Gpy2zLEM9vd3mU29zuicGGxI9172IoMrxIUb+2xHKNX7oqdXDAc7Fkie9+Rob4FLcBbC4jttnDk/EjyMjE52gZ12BbIGes9OL9a3Sj7QGPjnTCPliwohkebAy7SkK4HbpHriJ7TqA1TxGBTM80g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768638; c=relaxed/simple; bh=S2a1Kw0sC3CsXwE/Uet1J3QooijcrYchVxhPMvMQoO4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YUhElqtpZ6dyVUI7ONuzp31WBT6K0464MWQi4Sv8b4QviOXXstRINjl/6cWQLuuVYsbCz86F2u4Qm6eCxiuTDu207MouAtINLtu2QoCiOySe7ilkYc7eV887+aPCufg9Cr67Gfgzfd8adbOJXUYPchnTGxvGlrIvQS2OBfQCvNc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=IAf8Yf83; arc=none smtp.client-ip=109.224.244.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="IAf8Yf83" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761768631; x=1762027831; bh=S2a1Kw0sC3CsXwE/Uet1J3QooijcrYchVxhPMvMQoO4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=IAf8Yf83jJpokLTSbKrc6oZO27DAaw7BQUnE7WCUryg0gLluEitf1I28vmC/H7oml bjw+r/ilmQ+FUR4ZrZ/gaUrnBytCchvTJWpL3VZOkGgYjmYKURcbqbQHdnYxCYWLeN 9re+mOvg0PqgLR5FpUhW6rfiKnYi8Ry2ssLz3XCsOgvkpInMaxWEe+dOpc18CRsWgk 4N4hCGNQG4AJ6xEXdQIaI+pniq8mMD2ntUxxe+DxtFOWAvmeACobKS5Nqb1DTw+C6x xOus8MYRr0WlJflGSWspRnnlWmjeV4ZsSgXO8DpPRXLVZTHll8Qu+wV7nOCuGbYgBC QQZoRZPiCqMqQ== Date: Wed, 29 Oct 2025 20:10:26 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 16/18] arm64: Unify software tag-based KASAN inline recovery path Message-ID: <0a21096d806eafa679798b9844ec33bf8a5499a4.1761763681.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: ab91b91b5b8eb35edef4ae212700531bcd4f5e1b Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman To avoid having a copy of a long comment explaining the intricacies of the inline KASAN recovery system and issues for every architecture that uses the software tag-based mode, a unified kasan_die_unless_recover() function was added. Use kasan_die_unless_recover() in the kasan brk handler to cleanup the long comment, that's kept in the non-arch KASAN code. Signed-off-by: Maciej Wieczor-Retman Acked-by: Catalin Marinas Acked-by: Alexander Potapenko --- Changelog v6: - Add Catalin's Acked-by tag. Changelog v5: - Split arm64 portion of patch 13/18 into this one. (Peter Zijlstra) arch/arm64/kernel/traps.c | 17 +---------------- 1 file changed, 1 insertion(+), 16 deletions(-) diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index 681939ef5d16..b1efc11c3b5a 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -1071,22 +1071,7 @@ int kasan_brk_handler(struct pt_regs *regs, unsigned= long esr) =20 kasan_report(addr, size, write, pc); =20 - /* - * The instrumentation allows to control whether we can proceed after - * a crash was detected. This is done by passing the -recover flag to - * the compiler. Disabling recovery allows to generate more compact - * code. - * - * Unfortunately disabling recovery doesn't work for the kernel right - * now. KASAN reporting is disabled in some contexts (for example when - * the allocator accesses slab object metadata; this is controlled by - * current->kasan_depth). All these accesses are detected by the tool, - * even though the reports for them are not printed. - * - * This is something that might be fixed at some point in the future. - */ - if (!recover) - die("Oops - KASAN", regs, esr); + kasan_die_unless_recover(recover, "Oops - KASAN", regs, esr, die); =20 /* If thread survives, skip over the brk instruction and continue: */ arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE); --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch [79.135.106.30]) (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 CA0013590D5 for ; Wed, 29 Oct 2025 20:11:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.30 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768673; cv=none; b=O5od0cQXvGn8jc5ZH5FFk2GxqXbu3oH6z5lXXNMdzdpkFN5Xv5M6Zwt+Adc6fBsJRDzj4AGrtqqENB6gyk202AulOVLU2iMwJnHSgQkC9lVOQg4lZFF4WiJrNBSanegkCjKNnaIwAOhq4P/DmmCrkYUmwmIZJBQ10BVuvLTy3zc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768673; c=relaxed/simple; bh=j2uwSocT6IFw6bbQ1grp87Y3SKSODbUdA2TcfR9tSV8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BTGm++xACNV5CVsnH3QVrZivCgGoM6yB37uAsybTh+kviKgHWUXZ5JZIVLHz9m26kM7m405G8l+PFKNi8ow+EMrkJwnxCQasWfC2jAEXC+A2XuKqFeKFnl7RvpsTgeSJNqIPM9lNVnxe3xM43gS5UOkNegPpshUVU50Z3+1PnQ8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=fzcdT/Mg; arc=none smtp.client-ip=79.135.106.30 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="fzcdT/Mg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761768667; x=1762027867; bh=qpGuNHZZR4hchfLUKKttSmaxG+W37eMF01r5+dBbCBY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=fzcdT/Mg837dtUDPzN3IZvJaFmIR4Koi9D+v6niFRb/NDXYCqERKygFXgJXDi25Nv opesT+yY+ZAJxBCKk0ZbHNPb4MmR/qTVK0Z2Q1fl5bY9rdus7GvFftgsKs92S3Qtzm u8mvfXIT3aHxC5vDZBVshhQgdWJHoFxaxEJQtYDzMAhElAG7KvcXieapyAoWHrlRUN yJpUT363OVIiMLTqvxO9wi+6g5bah1gyRFRfq8Q1ReHcFkouvWUfWHp20CeXzhITsI U97+N2r0KUpsSmw9ebJH+rNIrUxQ1hFJolDaiMg/U/CTV4shVJNvcKz19+T0ukaPqk nmoReRkSuQ50g== Date: Wed, 29 Oct 2025 20:11:00 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 17/18] x86/kasan: Logical bit shift for kasan_mem_to_shadow Message-ID: <81848c9df2dc22e9d9104c8276879e6e849a5087.1761763681.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 1962ec27b7155c20b7f866d92710251ffdf5f53c Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman While generally tag-based KASAN adopts an arithemitc bit shift to convert a memory address to a shadow memory address, it doesn't work for all cases on x86. Testing different shadow memory offsets proved that either 4 or 5 level paging didn't work correctly or inline mode ran into issues. Thus the best working scheme is the logical bit shift and non-canonical shadow offset that x86 uses for generic KASAN, of course adjusted for the increased granularity from 8 to 16 bytes. Add an arch specific implementation of kasan_mem_to_shadow() that uses the logical bit shift. The non-canonical hook tries to calculate whether an address came from kasan_mem_to_shadow(). First it checks whether this address fits into the legal set of values possible to output from the mem to shadow function. Tie both generic and tag-based x86 KASAN modes to the address range check associated with generic KASAN. Signed-off-by: Maciej Wieczor-Retman --- Changelog v4: - Add this patch to the series. arch/x86/include/asm/kasan.h | 7 +++++++ mm/kasan/report.c | 5 +++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h index 375651d9b114..2372397bc3e5 100644 --- a/arch/x86/include/asm/kasan.h +++ b/arch/x86/include/asm/kasan.h @@ -49,6 +49,13 @@ #include =20 #ifdef CONFIG_KASAN_SW_TAGS +static inline void *__kasan_mem_to_shadow(const void *addr) +{ + return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT) + + KASAN_SHADOW_OFFSET; +} + +#define kasan_mem_to_shadow(addr) __kasan_mem_to_shadow(addr) #define __tag_shifted(tag) FIELD_PREP(GENMASK_ULL(60, 57), tag) #define __tag_reset(addr) (sign_extend64((u64)(addr), 56)) #define __tag_get(addr) ((u8)FIELD_GET(GENMASK_ULL(60, 57), (u64)addr)) diff --git a/mm/kasan/report.c b/mm/kasan/report.c index 50d487a0687a..fd8fe004b0c0 100644 --- a/mm/kasan/report.c +++ b/mm/kasan/report.c @@ -642,13 +642,14 @@ void kasan_non_canonical_hook(unsigned long addr) const char *bug_type; =20 /* - * For Generic KASAN, kasan_mem_to_shadow() uses the logical right shift + * For Generic KASAN and Software Tag-Based mode on the x86 + * architecture, kasan_mem_to_shadow() uses the logical right shift * and never overflows with the chosen KASAN_SHADOW_OFFSET values (on * both x86 and arm64). Thus, the possible shadow addresses (even for * bogus pointers) belong to a single contiguous region that is the * result of kasan_mem_to_shadow() applied to the whole address space. */ - if (IS_ENABLED(CONFIG_KASAN_GENERIC)) { + if (IS_ENABLED(CONFIG_KASAN_GENERIC) || IS_ENABLED(CONFIG_X86_64)) { if (addr < (unsigned long)kasan_mem_to_shadow((void *)(0UL)) || addr > (unsigned long)kasan_mem_to_shadow((void *)(~0UL))) return; --=20 2.51.0 From nobody Sun Dec 14 11:11:55 2025 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) (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 63FF635A13D for ; Wed, 29 Oct 2025 20:11:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.43.22 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768694; cv=none; b=oV4pr20NlKqj/tdWS2liOLslwww/03YUATIjClWzxBh5/Vv44OF7y86Rn9TjY3oMtC7tiojTst67+ICzr/yhZmaSE6sefaii/xFmxjV0Pay8Si+HgLMEvoClZRa31uqLIbHrBa75fObNaVR46oyvgsbT7pMElUqLhWKIK6Sng1o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761768694; c=relaxed/simple; bh=i2x6FuRzHHu3DqZfnTFMfT434IIQFJZMu963TwDZRwE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MLeQSBh8AnxvoVaqtLP+gEdz2ntnK6PrY5VxiZN/Q9fWe4Dld+CYXXYl72iEo+E+ZhTNfaDVTYhB9+SK469MjIj709rXhkASeXwYsGVvq0ikG8v4doRXrQuCJG79B5/2zGT1ZL0s9MubiOhDgFoWJANDfyGrZSG09P1fd/OroAk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=cXdMGkjY; arc=none smtp.client-ip=185.70.43.22 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="cXdMGkjY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1761768688; x=1762027888; bh=801m/BDnq+4IDZrRjH01sT6fZRZq5h0m340QBaMU7xk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=cXdMGkjYQPcz0Nv21dBbiab8WuIQ4hr8ZJRQqwUepbPD1rbiz/vhDeUFcNs+IGjar od6iv3/pch7jNVp38Q2cmI4VQR0pGdQZyx7xwgvOjcMGXYKinHJUeISc801+Y8WgrO SCNfKcZPXZtF2+rk0dIn06Lyyoiy42cPczWw1N9Ui8kQDW0LXKyASTAfV23YHt8/QB FHk6Lay8dA8JodN9I7Vt57QyS2WDP7aNMHr/4vq1HuuEYHnPPI3dMERBgdU9EwiM+L Mj22z+1Gh8UFKiZFiqV8G56jWG5bH3ehdlP3bMiXUuyMKOD3PJOh+zXTgfnU3nZFJH 7Bb570r+dWC+Q== Date: Wed, 29 Oct 2025 20:11:22 +0000 To: xin@zytor.com, peterz@infradead.org, kaleshsingh@google.com, kbingham@kernel.org, akpm@linux-foundation.org, nathan@kernel.org, ryabinin.a.a@gmail.com, dave.hansen@linux.intel.com, bp@alien8.de, morbo@google.com, jeremy.linton@arm.com, smostafa@google.com, kees@kernel.org, baohua@kernel.org, vbabka@suse.cz, justinstitt@google.com, wangkefeng.wang@huawei.com, leitao@debian.org, jan.kiszka@siemens.com, fujita.tomonori@gmail.com, hpa@zytor.com, urezki@gmail.com, ubizjak@gmail.com, ada.coupriediaz@arm.com, nick.desaulniers+lkml@gmail.com, ojeda@kernel.org, brgerst@gmail.com, elver@google.com, pankaj.gupta@amd.com, glider@google.com, mark.rutland@arm.com, trintaeoitogc@gmail.com, jpoimboe@kernel.org, thuth@redhat.com, pasha.tatashin@soleen.com, dvyukov@google.com, jhubbard@nvidia.com, catalin.marinas@arm.com, yeoreum.yun@arm.com, mhocko@suse.com, lorenzo.stoakes@oracle.com, samuel.holland@sifive.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, surenb@google.com, ardb@kernel.org, Liam.Howlett@oracle.com, nicolas.schier@linux.dev, ziy@nvidia.com, kas@kernel.org, tglx@linutronix.de, mingo@redhat.com, broonie@kernel.org, corbet@lwn.net, andreyknvl@gmail.com, maciej.wieczor-retman@intel.com, david@redhat.com, maz@kernel.org, rppt@kernel.org, will@kernel.org, luto@kernel.org From: Maciej Wieczor-Retman Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v6 18/18] x86/kasan: Make software tag-based kasan available Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: f951758d099748a231d1551fe212ba144d88e29b Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman Make CONFIG_KASAN_SW_TAGS available for x86 machines if they have ADDRESS_MASKING enabled (LAM) as that works similarly to Top-Byte Ignore (TBI) that allows the software tag-based mode on arm64 platform. Set scale macro based on KASAN mode: in software tag-based mode 16 bytes of memory map to one shadow byte and 8 in generic mode. Disable CONFIG_KASAN_INLINE and CONFIG_KASAN_STACK when CONFIG_KASAN_SW_TAGS is enabled on x86 until the appropriate compiler support is available. Signed-off-by: Maciej Wieczor-Retman --- Changelog v6: - Don't enable KASAN if LAM is not supported. - Move kasan_init_tags() to kasan_init_64.c to not clutter the setup.c file. - Move the #ifdef for the KASAN scale shift here. - Move the gdb code to patch "Use arithmetic shift for shadow computation". - Return "depends on KASAN" line to Kconfig. - Add the defer kasan config option so KASAN can be disabled on hardware that doesn't have LAM. Changelog v4: - Add x86 specific kasan_mem_to_shadow(). - Revert x86 to the older unsigned KASAN_SHADOW_OFFSET. Do the same to KASAN_SHADOW_START/END. - Modify scripts/gdb/linux/kasan.py to keep x86 using unsigned offset. - Disable inline and stack support when software tags are enabled on x86. Changelog v3: - Remove runtime_const from previous patch and merge the rest here. - Move scale shift definition back to header file. - Add new kasan offset for software tag based mode. - Fix patch message typo 32 -> 16, and 16 -> 8. - Update lib/Kconfig.kasan with x86 now having software tag-based support. Changelog v2: - Remove KASAN dense code. Documentation/arch/x86/x86_64/mm.rst | 6 ++++-- arch/x86/Kconfig | 4 ++++ arch/x86/boot/compressed/misc.h | 1 + arch/x86/include/asm/kasan.h | 4 ++++ arch/x86/mm/kasan_init_64.c | 5 +++++ lib/Kconfig.kasan | 3 ++- 6 files changed, 20 insertions(+), 3 deletions(-) diff --git a/Documentation/arch/x86/x86_64/mm.rst b/Documentation/arch/x86/= x86_64/mm.rst index a6cf05d51bd8..ccbdbb4cda36 100644 --- a/Documentation/arch/x86/x86_64/mm.rst +++ b/Documentation/arch/x86/x86_64/mm.rst @@ -60,7 +60,8 @@ Complete virtual memory map with 4-level page tables ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused= hole ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual me= mory map (vmemmap_base) ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused= hole - ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shad= ow memory + ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shad= ow memory (generic mode) + fffff40000000000 | -8 TB | fffffbffffffffff | 8 TB | KASAN shad= ow memory (software tag-based mode) __________________|____________|__________________|_________|___________= _________________________________________________ | | Identical = layout to the 56-bit one from here on: @@ -130,7 +131,8 @@ Complete virtual memory map with 5-level page tables ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused= hole ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual me= mory map (vmemmap_base) ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused= hole - ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shad= ow memory + ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shad= ow memory (generic mode) + ffeffc0000000000 | -6 PB | fffffbffffffffff | 4 PB | KASAN shad= ow memory (software tag-based mode) __________________|____________|__________________|_________|___________= _________________________________________________ | | Identical = layout to the 47-bit one from here on: diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index fa3b616af03a..7c73a2688172 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -67,6 +67,7 @@ config X86 select ARCH_CLOCKSOURCE_INIT select ARCH_CONFIGURES_CPU_MITIGATIONS select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE + select ARCH_DISABLE_KASAN_INLINE if X86_64 && KASAN_SW_TAGS select ARCH_ENABLE_HUGEPAGE_MIGRATION if X86_64 && HUGETLB_PAGE && MIGRAT= ION select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG @@ -196,6 +197,8 @@ config X86 select HAVE_ARCH_JUMP_LABEL_RELATIVE select HAVE_ARCH_KASAN if X86_64 select HAVE_ARCH_KASAN_VMALLOC if X86_64 + select HAVE_ARCH_KASAN_SW_TAGS if ADDRESS_MASKING + select ARCH_NEEDS_DEFER_KASAN if ADDRESS_MASKING select HAVE_ARCH_KFENCE select HAVE_ARCH_KMSAN if X86_64 select HAVE_ARCH_KGDB @@ -406,6 +409,7 @@ config AUDIT_ARCH config KASAN_SHADOW_OFFSET hex depends on KASAN + default 0xeffffc0000000000 if KASAN_SW_TAGS default 0xdffffc0000000000 =20 config HAVE_INTEL_TXT diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/mis= c.h index db1048621ea2..ded92b439ada 100644 --- a/arch/x86/boot/compressed/misc.h +++ b/arch/x86/boot/compressed/misc.h @@ -13,6 +13,7 @@ #undef CONFIG_PARAVIRT_SPINLOCKS #undef CONFIG_KASAN #undef CONFIG_KASAN_GENERIC +#undef CONFIG_KASAN_SW_TAGS =20 #define __NO_FORTIFY =20 diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h index 2372397bc3e5..8320fffc71a1 100644 --- a/arch/x86/include/asm/kasan.h +++ b/arch/x86/include/asm/kasan.h @@ -7,6 +7,7 @@ #include #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL) =20 +#ifdef CONFIG_KASAN_SW_TAGS /* * LLVM ABI for reporting tag mismatches in inline KASAN mode. * On x86 the UD1 instruction is used to carry metadata in the ECX register @@ -24,7 +25,10 @@ #define KASAN_ECX_WRITE 0x10 #define KASAN_ECX_SIZE_MASK 0x0f #define KASAN_ECX_SIZE(ecx) (1 << ((ecx) & KASAN_ECX_SIZE_MASK)) +#define KASAN_SHADOW_SCALE_SHIFT 4 +#else #define KASAN_SHADOW_SCALE_SHIFT 3 +#endif =20 /* * Compiler uses shadow offset assuming that addresses start diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c index e69b7210aaae..4a5a4a4d43db 100644 --- a/arch/x86/mm/kasan_init_64.c +++ b/arch/x86/mm/kasan_init_64.c @@ -465,4 +465,9 @@ void __init kasan_init(void) =20 init_task.kasan_depth =3D 0; kasan_init_generic(); + + if (boot_cpu_has(X86_FEATURE_LAM)) + kasan_init_sw_tags(); + else + pr_info("KernelAddressSanitizer not initialized (sw-tags): hardware does= n't support LAM\n"); } diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan index a4bb610a7a6f..d13ea8da7bfd 100644 --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -112,7 +112,8 @@ config KASAN_SW_TAGS =20 Requires GCC 11+ or Clang. =20 - Supported only on arm64 CPUs and relies on Top Byte Ignore. + Supported on arm64 CPUs that support Top Byte Ignore and on x86 CPUs + that support Linear Address Masking. =20 Consumes about 1/16th of available memory at kernel start and add an overhead of ~20% for dynamic allocations. --=20 2.51.0