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 70CE6CE8D6B for ; Mon, 17 Nov 2025 18:26:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D096B8E000E; Mon, 17 Nov 2025 13:26:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CE09C8E0002; Mon, 17 Nov 2025 13:26:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1E058E000E; Mon, 17 Nov 2025 13:26:35 -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 B04BF8E0002 for ; Mon, 17 Nov 2025 13:26:35 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7BA44140181 for ; Mon, 17 Nov 2025 18:26:35 +0000 (UTC) X-FDA: 84120929550.08.392DE4E Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by imf13.hostedemail.com (Postfix) with ESMTP id 9F10020018 for ; Mon, 17 Nov 2025 18:26:33 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=pm.me header.s=protonmail3 header.b=BmWBhb8y; dmarc=pass (policy=quarantine) header.from=pm.me; spf=pass (imf13.hostedemail.com: domain of m.wieczorretman@pm.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=m.wieczorretman@pm.me ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1763403993; a=rsa-sha256; cv=none; b=tH0y6YswHg7oGyd99CTMfMhch5tWVaP7Tmg9LFmvloXPU8tYgyon92Jz+BXw3dauZov2+Z IQ0/OW58aFPvLKiY1my4HcYylRmLfu6KLEXcaHaTgmK9O1N7YWjMBdliNYfLDjfOHMa8lk LrZ7lxAwkdv5RZ1EdWqwO9mnpvJx5Xo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=pm.me header.s=protonmail3 header.b=BmWBhb8y; dmarc=pass (policy=quarantine) header.from=pm.me; spf=pass (imf13.hostedemail.com: domain of m.wieczorretman@pm.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=m.wieczorretman@pm.me ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1763403993; 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=jouESHi5Un7Q4FQfUgenF4mt4d6TLFLTX4D6FWFBOHM=; b=EqNEL6QnucBhyHlj2c2UFQ7pibfyUDcKD4HcWkZw34mO2Q8WPzuquzuBHDRxbtnK9PVQBa pd0t7zj8izYKh0tGsHnSMblL1Z+Xyam1Mkl9DQhoArBbmf5sYjAKr/d0P/vRqqK/gslrAJ jmmQL682Y/sKQ6fFEtvY9Vofon30Qcw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1763403989; x=1763663189; bh=jouESHi5Un7Q4FQfUgenF4mt4d6TLFLTX4D6FWFBOHM=; 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=BmWBhb8y1FXM46T3k5IgDeJH5cCnNwdX38PAg9lzWMGxrVMiyp8NjPRQTcbbizj/g 69t7L4LA6qkWLHLkecbAmKQQGuetVTM/wd/mam+8EdCUhEFIF/ePa2kL3qNFLs/oKf Ibp3gCduBQaHDuUnc5YuBREn1r1alTqghFjCtT61nSKBlVrreJAxM5AOENEeWn/NKY LtzDBqcziU0aSFhb4e+z6Qfc0iX6ZA/HOIiaTniVoNWx5qAsltTOCdg18CfUaVsDSw YXNcI8U1iKzDsIAqfLAmKnuavaj/0s3FKw+fpYq6N5HkiIujW6erJDxznrFLNqHCZZ ubSe2mMF0zVjw== Date: Mon, 17 Nov 2025 18:26:19 +0000 To: Marco Elver From: =?utf-8?Q?Maciej_Wiecz=C3=B3r-Retman?= Cc: 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, 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 17/18] x86/kasan: Logical bit shift for kasan_mem_to_shadow Message-ID: In-Reply-To: References: <81848c9df2dc22e9d9104c8276879e6e849a5087.1761763681.git.m.wieczorretman@pm.me> Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 8d14ced91bdd2f91cd367e805c79e65e22e0506e MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9F10020018 X-Stat-Signature: ehhr74haj97my37n9ej6yrmnhi6eejf5 X-HE-Tag: 1763403993-391340 X-HE-Meta: U2FsdGVkX1+dKZkcsILs5542dnUw72y5j17+NhVXgmvrhRGiONh5zhVeejXwG6dOaVnDb5RPTuXVEOJMOw2jx0Z/7/IQDXv7VRk4i0t/2PnI7vUEvyIcsjjXBFQaxclxyTGiBvLSeAVLir4G2MVbelR+FgSnFQfTSx/u6StT/7BcR4369MuvVeg7OboCuK2Ys8xuHPAhO9xeWvaIlGhRirRQSpYl8NV6O6e7aj6sI7CavRP9mGAzUnVaSUyp/AUTjbIng0GZEzt+mYruYZdvyoVm5PfHullVjpvY+YFeVS236XqMJbel1MN8b2KwiMd7Dy13jAq1cxwxm5L3H/WK2LB75zixJaRy86ZYh2W/eJalk37hHzbq+gcJWLwFaXtRv0kWrkcJul67U/pfw8T6fFOTcahF1QgY1SsM1qHOKWJ4NLix7yzZOl2/30t1VZFqhjkG4P6pw7bBQj238LHXr3ONfbTMLHtl/K5E/ZwOvBLLOFHZKo3aq/plJiWHxcri6K00HInz0dUPGmZRuWhg8Bu33IbNkMn93cPs/aWP3toDmDNGSVubB9cjAVz+OX1kTXUyQMZeu/a3PQgApyYwkc1TfWUUh5pZT0IdOIhE1LVB6fTcfjmiQfeD37wPVHamdgVlmJn5luTl292IP8Fjz0o9Ux0h7l34nEtnZBFDrQ+cM1I7LFkbzyECIC4ass/kN5buA9JQsXUt882rsOeXPqqhL3rwwvRYX0rHtJQ3ZUr4qV4j+JGzvoJ+A7sFnDHbPLeZJiXXIbS4UubFIXp8m8uAzCpuJWpZavoHLC9x0rIRCd9IlhYjPyTvW24hcSKhv/JQELQM7UzdhHGKnGAEvyPSf3kxBM9hFTQzD5B/5ipNPsD9tM9fUW8ikLRpp0xp5q4xowyMeST5JV3P3iaJUhj1sx8NA2yJJIPlPTyL/V6Y3HFpKPKTUYogX/YGRw4yEnXFIL6DnEhCgwmymvl uWe/tJl2 TmJ8Sl6R+9rU+yhlBr4VkUmhnGHQ5jHVPTl8JEFEhNn/L5L2ts8JDndTv8jNhu389qOJwfek7XTGyGGtGdngTPpvTBZWwEwCK7xIrFjgroIIvwF1koc/cZ4snlsYgFDB0XsNEnB/m4M4C6Ikui4PmUPm2oWQWbjaXJqTCqA9MI1qYp0pDVmXA3hkQfSRF3pQ4tPhof4UHyGHoDoLEo7YSvchln3V2ha2y24O007YdcrcGdG8mkI4yEW9suP+zyFrSIPDtolSx0RTAIcTG2ikD5bh/Kq9czo6Hpd6nsFLd2VrxONBjxPVKthMkwkeTrJ+wWrWt+Fg9J2+Ily2ukREX9n+pTfdtl5zkACTtDNgTUvhr1WnG2HC3yhX6CpGIWfum3PheLkPNq/TfFLyNaWnq3hf3E5LzDPdOZmrG 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-10 at 15:49:22 +0100, Marco Elver wrote: >On Wed, 29 Oct 2025 at 21:11, Maciej Wieczor-Retman > wrote: >> >> 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 >> >> #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; >> +} > >You're effectively undoing "kasan: sw_tags: Use arithmetic shift for >shadow computation" for x86 - why? >This function needs a comment explaining this. Sure, I'll add a comment here. While the signed approach seems to work well for arm64 and risc-v it doesn't play well with x86 which wants to keep the top bit for canonicality checks. Trying to keep signed mem to shadow scheme for all corner cases on all configs always turned into ugly workarounds for something. There is a mechanism, when there is a fault, to guess if the address came from a KASAN check - some address format always didn't work when I tried validating 4 and 5 paging levels. One approach to getting the signed mem to shadow was also using a non-canonial kasan shadow offset. It worked great for paging as far as I remember (some 5 lvl fixup code could be removed) but it made the inline mode either hard to implement or much slower due to extended checks. >Also, the commit message just says "it doesn't work for all cases" - why? Fair enough, this was a little not verbose. I'll update the patch message with an explanation.