* [PATCH v8 03/14] kasan: Fix inline mode for x86 tag-based mode
2026-01-12 17:26 [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Maciej Wieczor-Retman
@ 2026-01-12 17:27 ` Maciej Wieczor-Retman
2026-01-16 13:33 ` Andrey Ryabinin
2026-01-12 18:29 ` [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Andrew Morton
` (2 subsequent siblings)
3 siblings, 1 reply; 14+ messages in thread
From: Maciej Wieczor-Retman @ 2026-01-12 17:27 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Nathan Chancellor,
Nicolas Schier, Nick Desaulniers, Bill Wendling, Justin Stitt
Cc: m.wieczorretman, Maciej Wieczor-Retman, kasan-dev, linux-kbuild,
linux-kernel, llvm
From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
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 <maciej.wieczor-retman@intel.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Reviewed-by: Alexander Potapenko <glider@google.com>
---
Changelog v7:
- Add Alexander's Reviewed-by tag.
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 := -fsanitize=kernel-hwaddress
RUSTFLAGS_KASAN := -Zsanitizer=kernel-hwaddress \
-Zsanitizer-recover=kernel-hwaddress
+# 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 += hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET)
+ kasan_params += hwasan-instrument-with-calls=0
else
kasan_params += hwasan-instrument-with-calls=1
endif
--
2.52.0
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH v8 03/14] kasan: Fix inline mode for x86 tag-based mode
2026-01-12 17:27 ` [PATCH v8 03/14] kasan: Fix inline mode for x86 tag-based mode Maciej Wieczor-Retman
@ 2026-01-16 13:33 ` Andrey Ryabinin
0 siblings, 0 replies; 14+ messages in thread
From: Andrey Ryabinin @ 2026-01-16 13:33 UTC (permalink / raw)
To: Maciej Wieczor-Retman, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Nathan Chancellor,
Nicolas Schier, Nick Desaulniers, Bill Wendling, Justin Stitt
Cc: Maciej Wieczor-Retman, kasan-dev, linux-kbuild, linux-kernel,
llvm
On 1/12/26 6:27 PM, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>
> 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 <maciej.wieczor-retman@intel.com>
> Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
> Reviewed-by: Alexander Potapenko <glider@google.com>
> ---
Reviewed-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-12 17:26 [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Maciej Wieczor-Retman
2026-01-12 17:27 ` [PATCH v8 03/14] kasan: Fix inline mode for x86 tag-based mode Maciej Wieczor-Retman
@ 2026-01-12 18:29 ` Andrew Morton
2026-01-12 20:08 ` Maciej Wieczór-Retman
` (2 more replies)
2026-01-13 1:44 ` Andrey Konovalov
2026-01-19 16:33 ` Andrey Ryabinin
3 siblings, 3 replies; 14+ messages in thread
From: Andrew Morton @ 2026-01-12 18:29 UTC (permalink / raw)
To: Maciej Wieczor-Retman
Cc: corbet, morbo, rppt, lorenzo.stoakes, ubizjak, mingo,
vincenzo.frascino, maciej.wieczor-retman, maz, catalin.marinas,
yeoreum.yun, will, jackmanb, samuel.holland, glider, osandov, nsc,
luto, jpoimboe, Liam.Howlett, kees, jan.kiszka, thomas.lendacky,
jeremy.linton, dvyukov, axelrasmussen, leitao, ryabinin.a.a,
bigeasy, peterz, mark.rutland, urezki, brgerst, hpa, mhocko,
andreyknvl, weixugc, kbingham, vbabka, nathan, trintaeoitogc,
samitolvanen, tglx, thuth, surenb, anshuman.khandual, smostafa,
yuanchu, ada.coupriediaz, dave.hansen, kas, nick.desaulniers+lkml,
david, bp, ardb, justinstitt, linux-kernel, linux-mm, kasan-dev,
llvm, linux-arm-kernel, linux-doc, linux-kbuild, x86
On Mon, 12 Jan 2026 17:26:29 +0000 Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote:
> The patchset aims to add a KASAN tag-based mode for the x86 architecture
> with the help of the new CPU feature called Linear Address Masking
> (LAM). Main improvement introduced by the series is 2x lower memory
> usage compared to KASAN's generic mode, the only currently available
> mode on x86. The tag based mode may also find errors that the generic
> mode couldn't because of differences in how these modes operate.
Well this is a hearty mixture of arm, x86 and MM. I guess that means
mm.git.
The review process seems to be proceeding OK so I'll add this to
mm.git's mm-new branch, which is not included in linux-next. I'll aim
to hold it there for a week while people check the patches over and
send out their acks (please). Then I hope I can move it into mm.git's
mm-unstable branch where it will receive linux-next exposure.
> [1] Currently inline mode doesn't work on x86 due to things missing in
> the compiler. I have written a patch for clang that seems to fix the
> inline mode and I was able to boot and check that all patches regarding
> the inline mode work as expected. My hope is to post the patch to LLVM
> once this series is completed, and then make inline mode available in
> the kernel config.
>
> [2] While I was able to boot the inline tag-based kernel with my
> compiler changes in a simulated environment, due to toolchain
> difficulties I couldn't get it to boot on the machine I had access to.
> Also boot time results from the simulation seem too good to be true, and
> they're much too worse for the generic case to be believable. Therefore
> I'm posting only results from the physical server platform.
>
> ======= Compilation
> Clang was used to compile the series (make LLVM=1) since gcc doesn't
> seem to have support for KASAN tag-based compiler instrumentation on
> x86.
OK, known issues and they are understandable. With this patchset is
there any way in which our testers can encounter these things? If so
can we make changes to protect them from hitting known issues?
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-12 18:29 ` [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Andrew Morton
@ 2026-01-12 20:08 ` Maciej Wieczór-Retman
2026-01-12 20:53 ` Andrew Morton
2026-01-12 20:27 ` Dave Hansen
2026-01-13 11:47 ` Borislav Petkov
2 siblings, 1 reply; 14+ messages in thread
From: Maciej Wieczór-Retman @ 2026-01-12 20:08 UTC (permalink / raw)
To: Andrew Morton
Cc: corbet, morbo, rppt, lorenzo.stoakes, ubizjak, mingo,
vincenzo.frascino, maciej.wieczor-retman, maz, catalin.marinas,
yeoreum.yun, will, jackmanb, samuel.holland, glider, osandov, nsc,
luto, jpoimboe, Liam.Howlett, kees, jan.kiszka, thomas.lendacky,
jeremy.linton, dvyukov, axelrasmussen, leitao, ryabinin.a.a,
bigeasy, peterz, mark.rutland, urezki, brgerst, hpa, mhocko,
andreyknvl, weixugc, kbingham, vbabka, nathan, trintaeoitogc,
samitolvanen, tglx, thuth, surenb, anshuman.khandual, smostafa,
yuanchu, ada.coupriediaz, dave.hansen, kas, nick.desaulniers+lkml,
david, bp, ardb, justinstitt, linux-kernel, linux-mm, kasan-dev,
llvm, linux-arm-kernel, linux-doc, linux-kbuild, x86
On 2026-01-12 at 10:29:57 -0800, Andrew Morton wrote:
>On Mon, 12 Jan 2026 17:26:29 +0000 Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote:
>
>> The patchset aims to add a KASAN tag-based mode for the x86 architecture
>> with the help of the new CPU feature called Linear Address Masking
>> (LAM). Main improvement introduced by the series is 2x lower memory
>> usage compared to KASAN's generic mode, the only currently available
>> mode on x86. The tag based mode may also find errors that the generic
>> mode couldn't because of differences in how these modes operate.
>
>Well this is a hearty mixture of arm, x86 and MM. I guess that means
>mm.git.
>
>The review process seems to be proceeding OK so I'll add this to
>mm.git's mm-new branch, which is not included in linux-next. I'll aim
>to hold it there for a week while people check the patches over and
>send out their acks (please). Then I hope I can move it into mm.git's
>mm-unstable branch where it will receive linux-next exposure.
Thank you :)
>
>> [1] Currently inline mode doesn't work on x86 due to things missing in
>> the compiler. I have written a patch for clang that seems to fix the
>> inline mode and I was able to boot and check that all patches regarding
>> the inline mode work as expected. My hope is to post the patch to LLVM
>> once this series is completed, and then make inline mode available in
>> the kernel config.
>>
>> [2] While I was able to boot the inline tag-based kernel with my
>> compiler changes in a simulated environment, due to toolchain
>> difficulties I couldn't get it to boot on the machine I had access to.
>> Also boot time results from the simulation seem too good to be true, and
>> they're much too worse for the generic case to be believable. Therefore
>> I'm posting only results from the physical server platform.
>>
>> ======= Compilation
>> Clang was used to compile the series (make LLVM=1) since gcc doesn't
>> seem to have support for KASAN tag-based compiler instrumentation on
>> x86.
>
>OK, known issues and they are understandable. With this patchset is
>there any way in which our testers can encounter these things? If so
>can we make changes to protect them from hitting known issues?
The gcc documentation states that the -fsanitize=kernel-hwaddress is
similar to -fsanitize=hwaddress, which only works on AArch64. So that
hints that it shouldn't work.
But while with KASAN sw_tags enabled the kernel compiles fine with gcc,
at least in my patched qemu it doesn't run. I remember Ada Couprie Diaz
mention that passing -march=arrowlake might help since the tag support
seems to be based on arch.
I'll check if there's a non-hacky way to have gcc work too, but perhaps
to minimize hitting known issue, for now HAVE_ARCH_KASAN_SW_TAGS should
be locked behind both ADDRESS_MASKING and CC_IS_CLANG in the Kconfig?
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-12 20:08 ` Maciej Wieczór-Retman
@ 2026-01-12 20:53 ` Andrew Morton
2026-01-13 1:47 ` Andrey Konovalov
0 siblings, 1 reply; 14+ messages in thread
From: Andrew Morton @ 2026-01-12 20:53 UTC (permalink / raw)
To: Maciej Wieczór-Retman
Cc: corbet, morbo, rppt, lorenzo.stoakes, ubizjak, mingo,
vincenzo.frascino, maciej.wieczor-retman, maz, catalin.marinas,
yeoreum.yun, will, jackmanb, samuel.holland, glider, osandov, nsc,
luto, jpoimboe, Liam.Howlett, kees, jan.kiszka, thomas.lendacky,
jeremy.linton, dvyukov, axelrasmussen, leitao, ryabinin.a.a,
bigeasy, peterz, mark.rutland, urezki, brgerst, hpa, mhocko,
andreyknvl, weixugc, kbingham, vbabka, nathan, trintaeoitogc,
samitolvanen, tglx, thuth, surenb, anshuman.khandual, smostafa,
yuanchu, ada.coupriediaz, dave.hansen, kas, nick.desaulniers+lkml,
david, bp, ardb, justinstitt, linux-kernel, linux-mm, kasan-dev,
llvm, linux-arm-kernel, linux-doc, linux-kbuild, x86
On Mon, 12 Jan 2026 20:08:23 +0000 Maciej Wieczór-Retman <m.wieczorretman@pm.me> wrote:
> >OK, known issues and they are understandable. With this patchset is
> >there any way in which our testers can encounter these things? If so
> >can we make changes to protect them from hitting known issues?
>
> The gcc documentation states that the -fsanitize=kernel-hwaddress is
> similar to -fsanitize=hwaddress, which only works on AArch64. So that
> hints that it shouldn't work.
>
> But while with KASAN sw_tags enabled the kernel compiles fine with gcc,
> at least in my patched qemu it doesn't run. I remember Ada Couprie Diaz
> mention that passing -march=arrowlake might help since the tag support
> seems to be based on arch.
>
> I'll check if there's a non-hacky way to have gcc work too, but perhaps
> to minimize hitting known issue, for now HAVE_ARCH_KASAN_SW_TAGS should
> be locked behind both ADDRESS_MASKING and CC_IS_CLANG in the Kconfig?
Yes please - my main concern is that we avoid causing any disruption to
testers/buildbots/fuzzers/etc.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-12 20:53 ` Andrew Morton
@ 2026-01-13 1:47 ` Andrey Konovalov
0 siblings, 0 replies; 14+ messages in thread
From: Andrey Konovalov @ 2026-01-13 1:47 UTC (permalink / raw)
To: Andrew Morton, Maciej Wieczór-Retman
Cc: corbet, morbo, rppt, lorenzo.stoakes, ubizjak, mingo,
vincenzo.frascino, maciej.wieczor-retman, maz, catalin.marinas,
yeoreum.yun, will, jackmanb, samuel.holland, glider, osandov, nsc,
luto, jpoimboe, Liam.Howlett, kees, jan.kiszka, thomas.lendacky,
jeremy.linton, dvyukov, axelrasmussen, leitao, ryabinin.a.a,
bigeasy, peterz, mark.rutland, urezki, brgerst, hpa, mhocko,
weixugc, kbingham, vbabka, nathan, trintaeoitogc, samitolvanen,
tglx, thuth, surenb, anshuman.khandual, smostafa, yuanchu,
ada.coupriediaz, dave.hansen, kas, nick.desaulniers+lkml, david,
bp, ardb, justinstitt, linux-kernel, linux-mm, kasan-dev, llvm,
linux-arm-kernel, linux-doc, linux-kbuild, x86
On Mon, Jan 12, 2026 at 9:53 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 12 Jan 2026 20:08:23 +0000 Maciej Wieczór-Retman <m.wieczorretman@pm.me> wrote:
>
> > >OK, known issues and they are understandable. With this patchset is
> > >there any way in which our testers can encounter these things? If so
> > >can we make changes to protect them from hitting known issues?
> >
> > The gcc documentation states that the -fsanitize=kernel-hwaddress is
> > similar to -fsanitize=hwaddress, which only works on AArch64. So that
> > hints that it shouldn't work.
> >
> > But while with KASAN sw_tags enabled the kernel compiles fine with gcc,
> > at least in my patched qemu it doesn't run. I remember Ada Couprie Diaz
> > mention that passing -march=arrowlake might help since the tag support
> > seems to be based on arch.
FYI, there are some known GCC issues with arm64 SW_TAGS mode as well:
https://bugzilla.kernel.org/show_bug.cgi?id=218043#c3.
> >
> > I'll check if there's a non-hacky way to have gcc work too, but perhaps
> > to minimize hitting known issue, for now HAVE_ARCH_KASAN_SW_TAGS should
> > be locked behind both ADDRESS_MASKING and CC_IS_CLANG in the Kconfig?
>
> Yes please - my main concern is that we avoid causing any disruption to
> testers/buildbots/fuzzers/etc.
I left some comments, but from my/KASAN point of view, the series is
ready for linux-next (but this could wait for a week and maybe the
next version of the series).
I wouldn't think there would be disruption issues: one would need to
deliberately enable the SW_TAGS mode for x86 (as GENERIC is the
default mode when just enabling KASAN). But I don't mind locking down
x86 SW_TAGS to be Clang-only for now if GCC is known not to work at
all.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-12 18:29 ` [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Andrew Morton
2026-01-12 20:08 ` Maciej Wieczór-Retman
@ 2026-01-12 20:27 ` Dave Hansen
2026-01-13 11:47 ` Borislav Petkov
2 siblings, 0 replies; 14+ messages in thread
From: Dave Hansen @ 2026-01-12 20:27 UTC (permalink / raw)
To: Andrew Morton, Maciej Wieczor-Retman
Cc: corbet, morbo, rppt, lorenzo.stoakes, ubizjak, mingo,
vincenzo.frascino, maciej.wieczor-retman, maz, catalin.marinas,
yeoreum.yun, will, jackmanb, samuel.holland, glider, osandov, nsc,
luto, jpoimboe, Liam.Howlett, kees, jan.kiszka, thomas.lendacky,
jeremy.linton, dvyukov, axelrasmussen, leitao, ryabinin.a.a,
bigeasy, peterz, mark.rutland, urezki, brgerst, hpa, mhocko,
andreyknvl, weixugc, kbingham, vbabka, nathan, trintaeoitogc,
samitolvanen, tglx, thuth, surenb, anshuman.khandual, smostafa,
yuanchu, ada.coupriediaz, dave.hansen, kas, nick.desaulniers+lkml,
david, bp, ardb, justinstitt, linux-kernel, linux-mm, kasan-dev,
llvm, linux-arm-kernel, linux-doc, linux-kbuild, x86
On 1/12/26 10:29, Andrew Morton wrote:
> On Mon, 12 Jan 2026 17:26:29 +0000 Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote:
>> The patchset aims to add a KASAN tag-based mode for the x86 architecture
>> with the help of the new CPU feature called Linear Address Masking
>> (LAM). Main improvement introduced by the series is 2x lower memory
>> usage compared to KASAN's generic mode, the only currently available
>> mode on x86. The tag based mode may also find errors that the generic
>> mode couldn't because of differences in how these modes operate.
> Well this is a hearty mixture of arm, x86 and MM. I guess that means
> mm.git.
>
> The review process seems to be proceeding OK so I'll add this to
> mm.git's mm-new branch, which is not included in linux-next. I'll aim
> to hold it there for a week while people check the patches over and
> send out their acks (please). Then I hope I can move it into mm.git's
> mm-unstable branch where it will receive linux-next exposure.
Yeah, it'll be good to get it some more testing exposure.
But, we definitely don't want it going upstream until it's more
thoroughly reviewed than it stands. Maciej, this would be a good time to
make sure you have a good idea who needs to review this and go rattle
some cages.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-12 18:29 ` [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Andrew Morton
2026-01-12 20:08 ` Maciej Wieczór-Retman
2026-01-12 20:27 ` Dave Hansen
@ 2026-01-13 11:47 ` Borislav Petkov
2026-01-13 17:34 ` Andrew Morton
2 siblings, 1 reply; 14+ messages in thread
From: Borislav Petkov @ 2026-01-13 11:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Maciej Wieczor-Retman, corbet, morbo, rppt, lorenzo.stoakes,
ubizjak, mingo, vincenzo.frascino, maciej.wieczor-retman, maz,
catalin.marinas, yeoreum.yun, will, jackmanb, samuel.holland,
glider, osandov, nsc, luto, jpoimboe, Liam.Howlett, kees,
jan.kiszka, thomas.lendacky, jeremy.linton, dvyukov,
axelrasmussen, leitao, ryabinin.a.a, bigeasy, peterz,
mark.rutland, urezki, brgerst, hpa, mhocko, andreyknvl, weixugc,
kbingham, vbabka, nathan, trintaeoitogc, samitolvanen, tglx,
thuth, surenb, anshuman.khandual, smostafa, yuanchu,
ada.coupriediaz, dave.hansen, kas, nick.desaulniers+lkml, david,
ardb, justinstitt, linux-kernel, linux-mm, kasan-dev, llvm,
linux-arm-kernel, linux-doc, linux-kbuild, x86
On Mon, Jan 12, 2026 at 10:29:57AM -0800, Andrew Morton wrote:
> The review process seems to be proceeding OK so I'll add this to
> mm.git's mm-new branch, which is not included in linux-next. I'll aim
> to hold it there for a week while people check the patches over and
> send out their acks (please). Then I hope I can move it into mm.git's
> mm-unstable branch where it will receive linux-next exposure.
Yah, you can drop this one and take the next revision after all comments have
been addressed.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-13 11:47 ` Borislav Petkov
@ 2026-01-13 17:34 ` Andrew Morton
2026-01-22 17:25 ` Maciej Wieczor-Retman
0 siblings, 1 reply; 14+ messages in thread
From: Andrew Morton @ 2026-01-13 17:34 UTC (permalink / raw)
To: Borislav Petkov
Cc: Maciej Wieczor-Retman, corbet, morbo, rppt, lorenzo.stoakes,
ubizjak, mingo, vincenzo.frascino, maciej.wieczor-retman, maz,
catalin.marinas, yeoreum.yun, will, jackmanb, samuel.holland,
glider, osandov, nsc, luto, jpoimboe, Liam.Howlett, kees,
jan.kiszka, thomas.lendacky, jeremy.linton, dvyukov,
axelrasmussen, leitao, ryabinin.a.a, bigeasy, peterz,
mark.rutland, urezki, brgerst, hpa, mhocko, andreyknvl, weixugc,
kbingham, vbabka, nathan, trintaeoitogc, samitolvanen, tglx,
thuth, surenb, anshuman.khandual, smostafa, yuanchu,
ada.coupriediaz, dave.hansen, kas, nick.desaulniers+lkml, david,
ardb, justinstitt, linux-kernel, linux-mm, kasan-dev, llvm,
linux-arm-kernel, linux-doc, linux-kbuild, x86
On Tue, 13 Jan 2026 12:47:05 +0100 Borislav Petkov <bp@alien8.de> wrote:
> On Mon, Jan 12, 2026 at 10:29:57AM -0800, Andrew Morton wrote:
> > The review process seems to be proceeding OK so I'll add this to
> > mm.git's mm-new branch, which is not included in linux-next. I'll aim
> > to hold it there for a week while people check the patches over and
> > send out their acks (please). Then I hope I can move it into mm.git's
> > mm-unstable branch where it will receive linux-next exposure.
>
> Yah, you can drop this one and take the next revision after all comments have
> been addressed.
Cool, I removed the series.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-13 17:34 ` Andrew Morton
@ 2026-01-22 17:25 ` Maciej Wieczor-Retman
0 siblings, 0 replies; 14+ messages in thread
From: Maciej Wieczor-Retman @ 2026-01-22 17:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Borislav Petkov, corbet, morbo, rppt, lorenzo.stoakes, ubizjak,
mingo, vincenzo.frascino, maciej.wieczor-retman, maz,
catalin.marinas, yeoreum.yun, will, jackmanb, samuel.holland,
glider, osandov, nsc, luto, jpoimboe, Liam.Howlett, kees,
jan.kiszka, thomas.lendacky, jeremy.linton, dvyukov,
axelrasmussen, leitao, ryabinin.a.a, bigeasy, peterz,
mark.rutland, urezki, brgerst, hpa, mhocko, andreyknvl, weixugc,
kbingham, vbabka, nathan, trintaeoitogc, samitolvanen, tglx,
thuth, surenb, anshuman.khandual, smostafa, yuanchu,
ada.coupriediaz, dave.hansen, kas, nick.desaulniers+lkml, david,
ardb, justinstitt, linux-kernel, linux-mm, kasan-dev, llvm,
linux-arm-kernel, linux-doc, linux-kbuild, x86
On 2026-01-13 at 09:34:00 -0800, Andrew Morton wrote:
>On Tue, 13 Jan 2026 12:47:05 +0100 Borislav Petkov <bp@alien8.de> wrote:
>
>> On Mon, Jan 12, 2026 at 10:29:57AM -0800, Andrew Morton wrote:
>> > The review process seems to be proceeding OK so I'll add this to
>> > mm.git's mm-new branch, which is not included in linux-next. I'll aim
>> > to hold it there for a week while people check the patches over and
>> > send out their acks (please). Then I hope I can move it into mm.git's
>> > mm-unstable branch where it will receive linux-next exposure.
>>
>> Yah, you can drop this one and take the next revision after all comments have
>> been addressed.
>
>Cool, I removed the series.
I sent v9 with (I hope) all comments addressed:
https://lore.kernel.org/all/cover.1768845098.git.m.wieczorretman@pm.me/
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-12 17:26 [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Maciej Wieczor-Retman
2026-01-12 17:27 ` [PATCH v8 03/14] kasan: Fix inline mode for x86 tag-based mode Maciej Wieczor-Retman
2026-01-12 18:29 ` [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Andrew Morton
@ 2026-01-13 1:44 ` Andrey Konovalov
2026-01-19 16:33 ` Andrey Ryabinin
3 siblings, 0 replies; 14+ messages in thread
From: Andrey Konovalov @ 2026-01-13 1:44 UTC (permalink / raw)
To: Maciej Wieczor-Retman
Cc: corbet, morbo, rppt, lorenzo.stoakes, ubizjak, mingo,
vincenzo.frascino, maciej.wieczor-retman, maz, catalin.marinas,
yeoreum.yun, will, jackmanb, samuel.holland, glider, osandov, nsc,
luto, jpoimboe, akpm, Liam.Howlett, kees, jan.kiszka,
thomas.lendacky, jeremy.linton, dvyukov, axelrasmussen, leitao,
ryabinin.a.a, bigeasy, peterz, mark.rutland, urezki, brgerst, hpa,
mhocko, weixugc, kbingham, vbabka, nathan, trintaeoitogc,
samitolvanen, tglx, thuth, surenb, anshuman.khandual, smostafa,
yuanchu, ada.coupriediaz, dave.hansen, kas, nick.desaulniers+lkml,
david, bp, ardb, justinstitt, linux-kernel, linux-mm, kasan-dev,
llvm, linux-arm-kernel, linux-doc, linux-kbuild, x86
On Mon, Jan 12, 2026 at 6:26 PM Maciej Wieczor-Retman
<m.wieczorretman@pm.me> wrote:
>
> ======= Introduction
> The patchset aims to add a KASAN tag-based mode for the x86 architecture
> with the help of the new CPU feature called Linear Address Masking
> (LAM). Main improvement introduced by the series is 2x lower memory
> usage compared to KASAN's generic mode, the only currently available
> mode on x86. The tag based mode may also find errors that the generic
> mode couldn't because of differences in how these modes operate.
>
> ======= How does KASAN' tag-based mode work?
> When enabled, memory accesses and allocations are augmented by the
> compiler during kernel compilation. Instrumentation functions are added
> to each memory allocation and each pointer dereference.
>
> The allocation related functions generate a random tag and save it in
> two places: in shadow memory that maps to the allocated memory, and in
> the top bits of the pointer that points to the allocated memory. Storing
> the tag in the top of the pointer is possible because of Top-Byte Ignore
> (TBI) on arm64 architecture and LAM on x86.
>
> The access related functions are performing a comparison between the tag
> stored in the pointer and the one stored in shadow memory. If the tags
> don't match an out of bounds error must have occurred and so an error
> report is generated.
>
> The general idea for the tag-based mode is very well explained in the
> series with the original implementation [1].
>
> [1] https://lore.kernel.org/all/cover.1544099024.git.andreyknvl@google.com/
>
> ======= Differences summary compared to the arm64 tag-based mode
> - Tag width:
> - Tag width influences the chance of a tag mismatch due to two
> tags from different allocations having the same value. The
> bigger the possible range of tag values the lower the chance
> of that happening.
> - Shortening the tag width from 8 bits to 4, while it can help
> with memory usage, it also increases the chance of not
> reporting an error. 4 bit tags have a ~7% chance of a tag
> mismatch.
>
> - Address masking mechanism
> - TBI in arm64 allows for storing metadata in the top 8 bits of
> the virtual address.
> - LAM in x86 allows storing tags in bits [62:57] of the pointer.
> To maximize memory savings the tag width is reduced to bits
> [60:57].
>
> - Inline mode mismatch reporting
> - Arm64 inserts a BRK instruction to pass metadata about a tag
> mismatch to the KASAN report.
> - Right now on x86 the INT3 instruction is used for the same
> purpose. The attempt to move it over to use UD1 is already
> implemented and tested but relies on another series that needs
> merging first. Therefore this patch will be posted separately
> once the dependency is satisfied by being merged upstream.
>
Please also update the Software Tag-Based KASAN section in
Documentation/dev-tools/kasan.rst accordingly.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-12 17:26 [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Maciej Wieczor-Retman
` (2 preceding siblings ...)
2026-01-13 1:44 ` Andrey Konovalov
@ 2026-01-19 16:33 ` Andrey Ryabinin
2026-01-19 19:43 ` Maciej Wieczor-Retman
3 siblings, 1 reply; 14+ messages in thread
From: Andrey Ryabinin @ 2026-01-19 16:33 UTC (permalink / raw)
To: Maciej Wieczor-Retman, corbet, morbo, rppt, lorenzo.stoakes,
ubizjak, mingo, vincenzo.frascino, maciej.wieczor-retman, maz,
catalin.marinas, yeoreum.yun, will, jackmanb, samuel.holland,
glider, osandov, nsc, luto, jpoimboe, akpm, Liam.Howlett, kees,
jan.kiszka, thomas.lendacky, jeremy.linton, dvyukov,
axelrasmussen, leitao, bigeasy, peterz, mark.rutland, urezki,
brgerst, hpa, mhocko, andreyknvl, weixugc, kbingham, vbabka,
nathan, trintaeoitogc, samitolvanen, tglx, thuth, surenb,
anshuman.khandual, smostafa, yuanchu, ada.coupriediaz,
dave.hansen, kas, nick.desaulniers+lkml, david, bp, ardb,
justinstitt
Cc: linux-kernel, linux-mm, kasan-dev, llvm, linux-arm-kernel,
linux-doc, linux-kbuild, x86
On 1/12/26 6:26 PM, Maciej Wieczor-Retman wrote:
> ======= Compilation
> Clang was used to compile the series (make LLVM=1) since gcc doesn't
> seem to have support for KASAN tag-based compiler instrumentation on
> x86.
>
It appears that GCC nominally supports this, but in practice it does not work.
Here is a minimal reproducer: https://godbolt.org/z/s85e11T5r
As far as I understand, calling a function through a tagged pointer is not
supported by the hardware, so GCC attempts to clear the tag before the call.
This behavior seems to be inherited from the userspace implementation of HWASan (-fsanitize=hwaddress).
I have filed a GCC bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123696
For the kernel, we probably do not want this masking at all, as effectively 99.9–100%
of function pointer calls are expected to be untagged anyway.
Clang does not appear to do this, not even for userspace.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86
2026-01-19 16:33 ` Andrey Ryabinin
@ 2026-01-19 19:43 ` Maciej Wieczor-Retman
0 siblings, 0 replies; 14+ messages in thread
From: Maciej Wieczor-Retman @ 2026-01-19 19:43 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: corbet, morbo, rppt, lorenzo.stoakes, ubizjak, mingo,
vincenzo.frascino, maciej.wieczor-retman, maz, catalin.marinas,
yeoreum.yun, will, jackmanb, samuel.holland, glider, osandov, nsc,
luto, jpoimboe, akpm, Liam.Howlett, kees, jan.kiszka,
thomas.lendacky, jeremy.linton, dvyukov, axelrasmussen, leitao,
bigeasy, peterz, mark.rutland, urezki, brgerst, hpa, mhocko,
andreyknvl, weixugc, kbingham, vbabka, nathan, trintaeoitogc,
samitolvanen, tglx, thuth, surenb, anshuman.khandual, smostafa,
yuanchu, ada.coupriediaz, dave.hansen, kas, nick.desaulniers+lkml,
david, bp, ardb, justinstitt, linux-kernel, linux-mm, kasan-dev,
llvm, linux-arm-kernel, linux-doc, linux-kbuild, x86
On 2026-01-19 at 17:33:35 +0100, Andrey Ryabinin wrote:
>On 1/12/26 6:26 PM, Maciej Wieczor-Retman wrote:
>
>> ======= Compilation
>> Clang was used to compile the series (make LLVM=1) since gcc doesn't
>> seem to have support for KASAN tag-based compiler instrumentation on
>> x86.
>>
>
>It appears that GCC nominally supports this, but in practice it does not work.
>Here is a minimal reproducer: https://godbolt.org/z/s85e11T5r
>
>As far as I understand, calling a function through a tagged pointer is not
>supported by the hardware, so GCC attempts to clear the tag before the call.
>This behavior seems to be inherited from the userspace implementation of HWASan (-fsanitize=hwaddress).
>
>I have filed a GCC bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123696
>
>For the kernel, we probably do not want this masking at all, as effectively 99.9–100%
>of function pointer calls are expected to be untagged anyway.
>
>Clang does not appear to do this, not even for userspace.
Cool, thanks, nice to know why the kernel didn't start with gcc.
I'm going to check in on the bug report every now and then and once it gets
resolved I'll test if everything works as expected on both compilers.
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply [flat|nested] 14+ messages in thread