| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <a4vtlaxadmqod44sriwf2b6cf5fzzvngl6f5s2vg6ziebahjtv@yctbqspkdn2b>
Date: Mon, 17 Nov 2025 09:47:20 +0000
From: Maciej Wieczór-Retman <m.wieczorretman@...me>
To: Peter Zijlstra <peterz@...radead.org>
Cc: xin@...or.com, kaleshsingh@...gle.com, kbingham@...nel.org, akpm@...ux-foundation.org, nathan@...nel.org, ryabinin.a.a@...il.com, dave.hansen@...ux.intel.com, bp@...en8.de, morbo@...gle.com, jeremy.linton@....com, smostafa@...gle.com, kees@...nel.org, baohua@...nel.org, vbabka@...e.cz, justinstitt@...gle.com, wangkefeng.wang@...wei.com, leitao@...ian.org, jan.kiszka@...mens.com, fujita.tomonori@...il.com, hpa@...or.com, urezki@...il.com, ubizjak@...il.com, ada.coupriediaz@....com, nick.desaulniers+lkml@...il.com, ojeda@...nel.org, brgerst@...il.com, elver@...gle.com, pankaj.gupta@....com, glider@...gle.com, mark.rutland@....com, trintaeoitogc@...il.com, jpoimboe@...nel.org, thuth@...hat.com, pasha.tatashin@...een.com, dvyukov@...gle.com, jhubbard@...dia.com, catalin.marinas@....com, yeoreum.yun@....com, mhocko@...e.com, lorenzo.stoakes@...cle.com, samuel.holland@...ive.com, vincenzo.frascino@....com, bigeasy@...utronix.de, surenb@...gle.com, ardb@...nel.org,
Liam.Howlett@...cle.com, nicolas.schier@...ux.dev, ziy@...dia.com, kas@...nel.org, tglx@...utronix.de, mingo@...hat.com, broonie@...nel.org, corbet@....net, andreyknvl@...il.com, maciej.wieczor-retman@...el.com, david@...hat.com, maz@...nel.org, rppt@...nel.org, will@...nel.org, luto@...nel.org, kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, x86@...nel.org, linux-kbuild@...r.kernel.org, linux-mm@...ck.org, llvm@...ts.linux.dev, linux-doc@...r.kernel.org
Subject: Re: [PATCH v6 15/18] x86/kasan: Handle UD1 for inline KASAN reports
On 2025-11-11 at 11:27:19 +0100, Peter Zijlstra wrote:
>On Wed, Oct 29, 2025 at 08:09:51PM +0000, Maciej Wieczor-Retman wrote:
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
>>
>> 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.
>>
>
>> 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 <linux/kasan-tags.h>
>> #include <linux/types.h>
>> #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
>
>> 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) == 0) /* EAX */
>> return BUG_UD1_UBSAN;
>>
>> + if (X86_MODRM_REG(v) == 1) /* ECX */
>> + return BUG_UD1_KASAN;
>> +
>> return BUG_UD1;
>> }
>>
>> @@ -357,6 +360,11 @@ static noinstr bool handle_bug(struct pt_regs *regs)
>> }
>> break;
>>
>> + case BUG_UD1_KASAN:
>> + kasan_inline_handler(regs);
>> + handled = true;
>> + break;
>> +
>> default:
>> break;
>> }
>
>> +void kasan_inline_handler(struct pt_regs *regs)
>> +{
>> + int metadata = regs->cx;
>> + u64 addr = regs->di;
>> + u64 pc = regs->ip;
>> + bool recover = metadata & KASAN_ECX_RECOVER;
>> + bool write = metadata & KASAN_ECX_WRITE;
>> + size_t size = 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);
>> +}
>
>I'm confused. Going by the ARM64 code, the meta-data is constant per
>site -- it is encoded in the break immediate.
>
>And I suggested you do the same on x86 by using the single byte
>displacement instruction encoding.
>
> ud1 0xFF(%ecx), %ecx
>
>Also, we don't have to use a fixed register for the address, you can do:
>
> ud1 0xFF(%ecx), %reg
>
>and have %reg tell us what register the address is in.
>
>Then you can recover the meta-data from the displacement immediate and
>the address from whatever register is denoted.
>
>This avoids the 'callsite' from having to clobber cx and move the address
>into di.
>
>What you have here will work, and I don't suppose we care about code
>density with KASAN much, but it could've been so much better :/
Thanks for checking the patch out, maybe I got too focused on just
getting clang to work. You're right, I'll try using the displacement
encoding.
I was attempting a few different encodings because clang was fussy about
putting data where I wanted it. The one in the patch worked fine and I
thought it'd be consistent with the form that UBSan uses. But yeah, I'll
work on it more.
I'll also go and rebase my series onto your WARN() hackery one since
there are a lot of changes to traps.c.
Powered by blists - more mailing lists