From nobody Thu Apr 2 01:37:36 2026 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 13DDF3148C9 for ; Mon, 30 Mar 2026 14:34:30 +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=1774881272; cv=none; b=cSa6vypBPMmP8RMuI7RYGKxNqv7/28Ebezh1n4kLoKMnYX8oS7gbGTMINOVUfKW2erjxigMJdxzCL7UO48+iWzuQvaUhLpFTjKu0hBdljWDA8MouY2Slx1Y9LaBSGZtjGuk+dVtnOBTf2U4dEqRW6cs61p50nY5BfciDSH7RauY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774881272; c=relaxed/simple; bh=LwNfxBWgQmpaN0N55me2m8MQEa8QkZFClIxbBKNRrBM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=C+5EilaTOgUcfdr9m35fZcmBCyivMMWvN34+P03hVbJwlmD3cpHyJo/QD8jFG+TVJbCU7HYoMM5RsA3zDLGh7eP6giMLGaGxZPZGUzc48woGzdUYKPFQRIIgvBidwxE5jMP3Qpt8Ru+uWFdMzrAOmpKlzp1jKU+tRp6U3IZ/QPI= 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=Cwa05oM8; 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="Cwa05oM8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1774881268; x=1775140468; bh=iGV4u3tIjmDilzg0P4gIC9AUsBUkKpvQgpSv2yugQhc=; 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=Cwa05oM82wFyg3lhhabVDaLk/BqvscLtdRojlYkkQXVtAIu8VoElb6AKtIkSvzXNG ClL8kHz5z4+IT1RgM5YuUyX8ziJo25NyBYYjawzm7goklxcP+AFOiK8kp5U+OMLr3h iVEHYX2EJZWcpVKeFi1X6dFTNpdR7m9QlFXhgjLqHWfEtWXsWeuYrP8STLTAEBCrcQ LHgkqG2/wExRgSRqxMa+hG1k5OeF7oUODrso93gwnZ1AFcroJy0sxBECAayt4O0eVn Mh7b3zyx9Y24hd/5BIAplMjQxyLl36Am3mpUZnClfzhtbkZRby9oTuMRTM7CFp9v5l YWr9nk4554Fpw== Date: Mon, 30 Mar 2026 14:34:25 +0000 To: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" From: Maciej Wieczor-Retman Cc: m.wieczorretman@pm.me, Maciej Wieczor-Retman , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org Subject: [PATCH v12 13/15] x86/kasan: Use a logical bit shift for kasan_mem_to_shadow Message-ID: <17b6cc428f2115fbb1421ace0143c9fc730bb166.1774872838.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 642f9f91beb2ffb0a81430d413c8865537107233 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 tag-based KASAN adopts an arithemitc bit shift to convert a memory address to a shadow memory address. While it makes a lot of sense on arm64, it doesn't work well for all cases on x86 - either the non-canonical hook becomes quite complex for different paging levels, or the inline mode would need a lot more adjustments. 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. Signed-off-by: Maciej Wieczor-Retman --- Changelog v11: - Remove arch_kasan_non_canonical_hook() since an arch independent version was added to the first patch in the series. Changelog v9: - Rename patch title so it fits the tip standards. - Take out the x86 part from mm/kasan/report.c and put it in the arch specific function. Adjust the patch message. Changelog v7: - Redo the patch message and add a comment to __kasan_mem_to_shadow() to provide better explanation on why x86 doesn't work well with the arithemitc bit shift approach (Marco). Changelog v4: - Add this patch to the series. arch/x86/include/asm/kasan.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h index c868ae734f68..060ef997bfae 100644 --- a/arch/x86/include/asm/kasan.h +++ b/arch/x86/include/asm/kasan.h @@ -31,6 +31,21 @@ #include =20 #ifdef CONFIG_KASAN_SW_TAGS +/* + * Using the non-arch specific implementation of __kasan_mem_to_shadow() w= ith a + * arithmetic bit shift can cause high code complexity in KASAN's non-cano= nical + * hook for x86 or might not work for some paging level and KASAN mode + * combinations. The inline mode compiler support could also suffer from h= igher + * complexity for no specific benefit. Therefore the generic mode's logical + * shift implementation is used. + */ +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)) --=20 2.53.0