From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C6F39CEACEF for ; Mon, 17 Nov 2025 09:47:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FC9F8E0010; Mon, 17 Nov 2025 04:47:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D48F8E0002; Mon, 17 Nov 2025 04:47:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2118E8E0010; Mon, 17 Nov 2025 04:47:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 036D78E0002 for ; Mon, 17 Nov 2025 04:47:37 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9A468BC054 for ; Mon, 17 Nov 2025 09:47:36 +0000 (UTC) X-FDA: 84119621712.19.AAF998D Received: from mail-106121.protonmail.ch (mail-106121.protonmail.ch [79.135.106.121]) by imf07.hostedemail.com (Postfix) with ESMTP id 9C3A740003 for ; Mon, 17 Nov 2025 09:47:34 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=pm.me header.s=protonmail3 header.b=mcrsu2KI; spf=pass (imf07.hostedemail.com: domain of m.wieczorretman@pm.me designates 79.135.106.121 as permitted sender) smtp.mailfrom=m.wieczorretman@pm.me; dmarc=pass (policy=quarantine) header.from=pm.me ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1763372855; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ihq7qfJz6+gs5FNsdIMwz9cXAydO9ORjjGo1TVl8LXw=; b=tXF3mYs3ZXtKsMFJkTYhpvMMqTJFVHwq2hUOBIHiaHeQPSjcdW7i+LKcHjMOjrM6q4S8Eq RAtxDkqXVn5Oi0466Kd19GAncJlfprNjjH9ShbnuVxIXsL+XLxqLw5XU3qeb9w6qocxV2m J9stmdKpQE4upVcT6GnTLYNbH9BW1I4= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=pm.me header.s=protonmail3 header.b=mcrsu2KI; spf=pass (imf07.hostedemail.com: domain of m.wieczorretman@pm.me designates 79.135.106.121 as permitted sender) smtp.mailfrom=m.wieczorretman@pm.me; dmarc=pass (policy=quarantine) header.from=pm.me ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1763372855; a=rsa-sha256; cv=none; b=S+/TmeGLkrqwrxG2npBPmzY+C99eeQBMcymWdSLTTo9LDMlYa2IqeG/5iK3j/qIicKXlG8 gvMojNI+QihsfAqTiS+FumuMllwJ+7Ho3gtc2hgoim+KvA7nOOwACBSRbRPGhY1vzthlVP GNdQr8jPCJ31oLsXL8fr6epbpA8wrNY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1763372848; x=1763632048; bh=ihq7qfJz6+gs5FNsdIMwz9cXAydO9ORjjGo1TVl8LXw=; 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=mcrsu2KIWRBuWP34fnaTEh2MJNkVwIexwJGZLPXXX8yXyfC6BVMRE0pwA0f836XBU UpCxiJRetz1cvCIHZAK97aG637iimF1G6z/rv35RGWp/5AHDknha1iBHirylJDw7M+ 306KxxrDTs2lhPnbOZQ8W//vM6e3Yq0mySSt3Jj72gcEiVI/wkkaKvxxXGcJFfbZGQ Xf3TP+8S6SNTxCKDROm1/FW3BdZ/Xx/MNDofPUimmPwmBY1JUkJsGtEbSHUpH0zpBu R4nsgQ8dvLZLK5ODLUBLrAnXcP6hEEmkdZOTveuEmMB8lVsdZigLkuR3CPDc5gq2r1 XrzHunj7MULtQ== Date: Mon, 17 Nov 2025 09:47:20 +0000 To: Peter Zijlstra From: =?utf-8?Q?Maciej_Wiecz=C3=B3r-Retman?= Cc: xin@zytor.com, 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, 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 Subject: Re: [PATCH v6 15/18] x86/kasan: Handle UD1 for inline KASAN reports Message-ID: In-Reply-To: <20251111102719.GH278048@noisy.programming.kicks-ass.net> References: <8b0daaf83752528418bf2dd8d08906c37fa31f69.1761763681.git.m.wieczorretman@pm.me> <20251111102719.GH278048@noisy.programming.kicks-ass.net> Feedback-ID: 164464600:user:proton X-Pm-Message-ID: c252819bcd42668f3ed4c2d3435f49dcbb5a823f MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 9C3A740003 X-Stat-Signature: d36h9cpzsunx7ipxn7kqee1n8zzh5hib X-Rspam-User: X-HE-Tag: 1763372854-100962 X-HE-Meta: U2FsdGVkX1+NMliQin5TMbD7QlmhGA8d/FawXyj0uRd6RaSiLWTH/nxmyMPWcZd/AXeFtGiIzRbG3tkCsd2dZrxaJTYyFvHzX7Fju+sjbfxvhhYp5DXbJJ4mUoNANzuw/B1X0ykj9jDJ+mtFrxLl6i/Fv/qoyk4fEu0xb6UYvePzP97S0qT56D+tLkBHjzvi6IwJPo7C73DgQU1sRzdMdWoDbo5nj8ydiu1qW5AkAu93G2yx2dvjJlmNblTTWf3Fxzn3ei0gJNi+vAxc6yTzA0/DPNhCHaZSZ3Y5bPbDnRoZa2swUnxR+KMl/HeGckhBCO9ExAGO35PwVkCE9OXojeFOLnaYvyLnBT7dkQSqQcdI9T9WcSYfKosmEla94rA2o0IUpTYHSJXKpFh/QCwlbufHcrEvEalS9rxd0wonJfzTG+qeg6h7D5lT7lV05W5uw1pKIojs0N72AHcLX7vjeSX0MXuRsjsvyg4Gc2BSxlQV76uZXw11kZAMKbgU/IIQxXtPBDYnUMJvGj5gj1XMjRh5gKf19CAoxDh5HMrXk94xy4gQONZbBrc7FRjlWRn8PHvYH0XPOiEvAY/MvIhkBt6UcA2A5RpX4jzyYaiqR9kuZL4EtF6iat8/y0kkHXRaiOxpa6oRUbV6JMnMyiFazrBeAspPelpREDnDN/NqC4lbHJfRXQ9rgFynYNsRn3y4AOumjr14F8W4gb7tkt4j8R5aRbx8dFRIYqFvxSSI9DWDzfhbDoX5QF8Qmnymn3n/Q/rpxwq533gNWzWjNelGocLtfK/IGtAAhwis7SowT7pLlgAGOHTVTIY1TFYVNkTrd9bnu0raRazk/0M3ls+3KalEIY1M7ZCx88KDgGccR7afAnok7220cGrl9yw5VoKp5CDLmvLCzCi5kcUvcmj8KTqXqcwxLjwX2ozjWP3MI8h4WV7V226nda/XFnrqHM9Zmrcf0pc/UGoJO3SdaD1 lgtIjUwq 916uPMYGUgFnWe3oa1TWD1K9r6Q4tuMhLjjv8WOIM3BYx65vwYx2vlHBqx6zKjPsXfP0Jh1F1VN58WxnzzFZm6cQ89zCaGziHOUVI8kn3NiiWqjK7/r1MroDe7mWe0HZfB7mGvC+ovq34o2mZp2Ep3umphDszkb2CeduFU/1l1dyjXBfv/m7uMpddr/Vm5tbbQIWQ530m+pfWC3xJHtwlNGJON4Rp6hOH7IOCd68ZxKIqvgFDOO+/wIR6PfyurdwczBkN50Ix0M5xAaZl50vCH3nGlJksfN3l/f1taIjojvo+YCTzG/P3j4Z7kLEwFGtTP3r71xKcuQeTj+o= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 >> >> 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 >> #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 regi= ster >> + * to the KASAN report. ECX is used to differentiate KASAN from UBSan w= hen >> + * 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=090x20 >> +#define KASAN_ECX_WRITE=09=090x10 >> +#define KASAN_ECX_SIZE_MASK=090x0f >> +#define KASAN_ECX_SIZE(ecx)=09(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, s= 32 *imm, int *len) >> =09if (X86_MODRM_REG(v) =3D=3D 0)=09/* EAX */ >> =09=09return BUG_UD1_UBSAN; >> >> +=09if (X86_MODRM_REG(v) =3D=3D 1)=09/* ECX */ >> +=09=09return BUG_UD1_KASAN; >> + >> =09return BUG_UD1; >> } >> >> @@ -357,6 +360,11 @@ static noinstr bool handle_bug(struct pt_regs *regs= ) >> =09=09} >> =09=09break; >> >> +=09case BUG_UD1_KASAN: >> +=09=09kasan_inline_handler(regs); >> +=09=09handled =3D true; >> +=09=09break; >> + >> =09default: >> =09=09break; >> =09} > >> +void kasan_inline_handler(struct pt_regs *regs) >> +{ >> +=09int metadata =3D regs->cx; >> +=09u64 addr =3D regs->di; >> +=09u64 pc =3D regs->ip; >> +=09bool recover =3D metadata & KASAN_ECX_RECOVER; >> +=09bool write =3D metadata & KASAN_ECX_WRITE; >> +=09size_t size =3D KASAN_ECX_SIZE(metadata); >> + >> +=09if (user_mode(regs)) >> +=09=09return; >> + >> +=09if (!kasan_report((void *)addr, size, write, pc)) >> +=09=09return; >> + >> +=09kasan_die_unless_recover(recover, "Oops - KASAN", regs, metadata, di= e); >> +} > >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. > >=09ud1=090xFF(%ecx), %ecx > >Also, we don't have to use a fixed register for the address, you can do: > >=09ud1=090xFF(%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.