From: Andrey Konovalov <andreyknvl@gmail.com>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Cc: Vitaly Buka <vitalybuka@google.com>,
kees@kernel.org, julian.stecklina@cyberus-technology.de,
kevinloughlin@google.com, peterz@infradead.org,
tglx@linutronix.de, justinstitt@google.com,
catalin.marinas@arm.com, wangkefeng.wang@huawei.com,
bhe@redhat.com, ryabinin.a.a@gmail.com,
kirill.shutemov@linux.intel.com, will@kernel.org,
ardb@kernel.org, jason.andryuk@amd.com,
dave.hansen@linux.intel.com, pasha.tatashin@soleen.com,
guoweikang.kernel@gmail.com, dwmw@amazon.co.uk,
mark.rutland@arm.com, broonie@kernel.org, apopple@nvidia.com,
bp@alien8.de, rppt@kernel.org, kaleshsingh@google.com,
richard.weiyang@gmail.com, luto@kernel.org, glider@google.com,
pankaj.gupta@amd.com, pawan.kumar.gupta@linux.intel.com,
kuan-ying.lee@canonical.com, tony.luck@intel.com, tj@kernel.org,
jgross@suse.com, dvyukov@google.com, baohua@kernel.org,
samuel.holland@sifive.com, dennis@kernel.org,
akpm@linux-foundation.org, thomas.weissschuh@linutronix.de,
surenb@google.com, kbingham@kernel.org, ankita@nvidia.com,
nathan@kernel.org, ziy@nvidia.com, xin@zytor.com,
rafael.j.wysocki@intel.com, andriy.shevchenko@linux.intel.com,
cl@linux.com, jhubbard@nvidia.com, hpa@zytor.com,
scott@os.amperecomputing.com, david@redhat.com,
jan.kiszka@siemens.com, vincenzo.frascino@arm.com,
corbet@lwn.net, maz@kernel.org, mingo@redhat.com, arnd@arndb.de,
ytcoode@gmail.com, xur@google.com, morbo@google.com,
thiago.bauermann@linaro.org, linux-doc@vger.kernel.org,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org, x86@kernel.org
Subject: Re: [PATCH v2 01/14] kasan: sw_tags: Use arithmetic shift for shadow computation
Date: Sat, 1 Mar 2025 01:21:52 +0100 [thread overview]
Message-ID: <CA+fCnZcDyS8FJwE6x66THExYU_t_n9cTA=9Qy3wL-RSssEb55g@mail.gmail.com> (raw)
In-Reply-To: <mjyjkyiyhbbxyksiycywgh72laozztzwxxwi3gi252uk4b6f7j@3zwpv7l7aisk>
[-- Attachment #1: Type: text/plain, Size: 2950 bytes --]
On Fri, Feb 28, 2025 at 5:13 PM Maciej Wieczor-Retman
<maciej.wieczor-retman@intel.com> wrote:
>
> I was applying your other comments to the series and came up with something like
> this. What do you think?
>
> /*
> * With the default kasan_mem_to_shadow() algorithm, all addresses
> * returned by the memory-to-shadow mapping (even for bogus pointers)
> * must be within a certain displacement from KASAN_SHADOW_OFFSET.
> *
> * For Generic KASAN the displacement is unsigned so the mapping from zero
> * to the last kernel address needs checking.
> */
> if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
> if (addr < KASAN_SHADOW_OFFSET ||
> addr >= KASAN_SHADOW_OFFSET + max_shadow_size)
> return;
> } else {
> /*
> * For the tag-based mode the compiler resets tags in addresses at
> * the start of kasan_mem_to_shadow(). Because of this it's not
> * necessary to check a mapping of the entire address space but only
> * whether a range of [0xFF00000000000000 - 0xFFFFFFFFFFFFFFFF] is a
> * valid memory-to-shadow mapping. On x86, tags are located in bits
> * 62:57 so the range becomes [0x7E00000000000000 - 0xFFFFFFFFFFFFFFFF].
> * The check below tries to exclude invalid addresses by
> * checking spaces between [0x7E00000000000000 - 0x7FFFFFFFFFFFFFFF]
> * (which are positive and will overflow the memory-to-shadow
> * mapping) and [0xFE00000000000000 - 0xFFFFFFFFFFFFFFFF]
> */
> if (addr > KASAN_SHADOW_OFFSET ||
> (addr < (u64)kasan_mem_to_shadow((void *)(0xFEUL << 56)) &&
> addr > (u64)kasan_mem_to_shadow((void *)(~0UL >> 1))) ||
> addr < (u64)kasan_mem_to_shadow((void *)(0x7EUL << 56)))
> return;
> }
>
> The comment is a bit long and has a lot of hexes but maybe it's good to leave a
> longer explanation so no one has to dig through the mailing archives to
> understand the logic :b
Explaining the logic sounds good to me!
I think your patch is close to what would look good, but I think the
parentheses in the long if condition look suspicious.
Please check the attached diff (Gmail makes it hard to inline code): I
fixed the parentheses (if I'm right about them being wrong), made the
checks look uniform, added an arm-specific check, and reworked the
comments (please check if they make sense).
If the diff looks good to you, let's use that.
It also would be great, if you could test this: add some code that
dereferences various bad addresses and see if the extra KASAN message
line gets printed during the GPF.
[-- Attachment #2: kasan_non_canonical_hook.patch --]
[-- Type: text/x-patch, Size: 2896 bytes --]
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 8357e1a33699..7edde1a26a41 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -681,11 +681,56 @@ void kasan_non_canonical_hook(unsigned long addr)
const char *bug_type;
/*
- * All addresses that came as a result of the memory-to-shadow mapping
- * (even for bogus pointers) must be >= KASAN_SHADOW_OFFSET.
+ * For Generic KASAN, kasan_mem_to_shadow() uses the logical right shift
+ * and never overflows with the chosen KASAN_SHADOW_OFFSET values (on
+ * both x86 and arm64). Thus, the possible shadow addresses (even for
+ * bogus pointers) belong to a single contiguous region that is the
+ * result of kasan_mem_to_shadow() applied to the whole address space.
*/
- if (addr < KASAN_SHADOW_OFFSET)
- return;
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
+ if (addr < (u64)kasan_mem_to_shadow((void *)(0UL)) ||
+ addr > (u64)kasan_mem_to_shadow((void *)(~0UL)))
+ return;
+ }
+
+ /*
+ * For Software Tag-Based KASAN, kasan_mem_to_shadow() uses the
+ * arithmetic shift. Normally, this would make checking for a possible
+ * shadow address complicated, as the shadow address computation
+ * operation would overflow only for some memory addresses. However, due
+ * to the chosen KASAN_SHADOW_OFFSET values and the fact the
+ * kasan_mem_to_shadow() only operates on pointers with the tag reset,
+ * the overflow always happens (for both x86 and arm64).
+ *
+ * For arm64, the top byte of the pointer gets reset to 0xFF. Thus, the
+ * possible shadow addresses belong to a region that is the result of
+ * kasan_mem_to_shadow() applied to the memory range
+ * [0xFF000000000000, 0xFFFFFFFFFFFFFFFF]. Despite the overflow, the
+ * resulting possible shadow region is contiguous, as the overflow
+ * happens for both 0xFF000000000000 and 0xFFFFFFFFFFFFFFFF.
+ */
+ if (IS_ENABLED(CONFIG_KASAN_SW_TAGS) && IS_ENABLED(CONFIG_ARM64)) {
+ if (addr < (u64)kasan_mem_to_shadow((void *)(0xFFUL << 56)) ||
+ addr > (u64)kasan_mem_to_shadow((void *)(~0UL)))
+ return;
+ }
+
+ /*
+ * For x86-64, only the pointer bits [62:57] get reset, and bits #63
+ * and #56 can be 0 or 1. Thus, kasan_mem_to_shadow() can be possibly
+ * applied to two regions of memory:
+ * [0x7E00000000000000, 0x7FFFFFFFFFFFFFFF] and
+ * [0xFE00000000000000, 0xFFFFFFFFFFFFFFFF]. As the overflow happens
+ * for both ends of both memory ranges, both possible shadow regions
+ * are contiguous.
+ */
+ if (IS_ENABLED(CONFIG_KASAN_SW_TAGS) && IS_ENABLED(CONFIG_X86_64)) {
+ if ((addr < (u64)kasan_mem_to_shadow((void *)(0x7EUL << 56)) ||
+ addr > (u64)kasan_mem_to_shadow((void *)(~0UL >> 1))) &&
+ (addr < (u64)kasan_mem_to_shadow((void *)(0xFEUL << 56)) ||
+ addr > (u64)kasan_mem_to_shadow((void *)(~0UL))))
+ return;
+ }
orig_addr = (unsigned long)kasan_shadow_to_mem((void *)addr);
next prev parent reply other threads:[~2025-03-01 0:22 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-18 8:15 [PATCH v2 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 01/14] kasan: sw_tags: Use arithmetic shift for shadow computation Maciej Wieczor-Retman
2025-02-19 23:29 ` Andrey Konovalov
2025-02-21 13:11 ` Maciej Wieczor-Retman
2025-02-22 15:06 ` Andrey Konovalov
2025-02-25 17:20 ` Maciej Wieczor-Retman
2025-02-25 19:12 ` Maciej Wieczor-Retman
2025-02-25 20:12 ` Maciej Wieczor-Retman
2025-02-25 21:38 ` Andrey Konovalov
2025-02-26 16:42 ` Maciej Wieczor-Retman
2025-02-26 19:44 ` Andrey Konovalov
2025-02-27 12:27 ` Maciej Wieczor-Retman
2025-02-28 16:12 ` Maciej Wieczor-Retman
2025-03-01 0:21 ` Andrey Konovalov [this message]
2025-03-04 14:06 ` Maciej Wieczor-Retman
2025-03-07 1:10 ` Andrey Konovalov
2025-03-13 14:56 ` Maciej Wieczor-Retman
2025-03-18 15:31 ` Andrey Konovalov
2025-02-25 21:37 ` Andrey Konovalov
2025-02-27 12:33 ` Maciej Wieczor-Retman
2025-03-01 0:22 ` Andrey Konovalov
2025-03-04 12:29 ` Maciej Wieczor-Retman
2025-03-07 1:10 ` Andrey Konovalov
2025-03-14 15:57 ` Maciej Wieczor-Retman
2025-03-18 15:32 ` Andrey Konovalov
2025-02-18 8:15 ` [PATCH v2 02/14] kasan: sw_tags: Check kasan_flag_enabled at runtime Maciej Wieczor-Retman
2025-02-19 23:30 ` Andrey Konovalov
2025-02-21 14:35 ` Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 03/14] kasan: sw_tags: Support outline stack tag generation Maciej Wieczor-Retman
2025-02-19 23:30 ` Andrey Konovalov
2025-02-18 8:15 ` [PATCH v2 04/14] kasan: sw_tags: Support tag widths less than 8 bits Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 05/14] kasan: arm64: x86: Make special tags arch specific Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 06/14] x86: Add arch specific kasan functions Maciej Wieczor-Retman
2025-02-19 23:30 ` Andrey Konovalov
2025-02-21 8:40 ` Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 07/14] x86: Reset tag for virtual to physical address conversions Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 08/14] x86: Physical address comparisons in fill_p*d/pte Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 09/14] mm: Pcpu chunk address tag reset Maciej Wieczor-Retman
2025-03-20 17:39 ` Andrey Ryabinin
2025-03-20 17:47 ` Andrey Konovalov
2025-03-21 10:40 ` Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 10/14] x86: KASAN raw shadow memory PTE init Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 11/14] x86: LAM initialization Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 12/14] x86: Minimal SLAB alignment Maciej Wieczor-Retman
2025-02-19 23:30 ` Andrey Konovalov
2025-02-21 7:24 ` Maciej Wieczor-Retman
2025-02-18 8:15 ` [PATCH v2 13/14] x86: runtime_const used for KASAN_SHADOW_END Maciej Wieczor-Retman
2025-02-19 23:31 ` Andrey Konovalov
2025-02-21 15:10 ` Maciej Wieczor-Retman
2025-02-21 15:27 ` Maciej Wieczor-Retman
2025-02-22 15:08 ` Andrey Konovalov
2025-02-22 15:07 ` Andrey Konovalov
2025-02-25 17:15 ` Maciej Wieczor-Retman
2025-02-25 21:37 ` Andrey Konovalov
2025-02-26 11:52 ` Maciej Wieczor-Retman
2025-02-26 15:24 ` Andrey Konovalov
2025-02-26 17:03 ` Maciej Wieczor-Retman
2025-03-21 19:20 ` Maciej Wieczor-Retman
2025-03-21 20:16 ` Andrey Konovalov
2025-03-24 10:43 ` Maciej Wieczor-Retman
2025-03-24 10:50 ` Maciej Wieczor-Retman
2025-03-24 21:58 ` Andrey Konovalov
2025-02-18 8:15 ` [PATCH v2 14/14] x86: Make software tag-based kasan available Maciej Wieczor-Retman
2025-02-19 23:31 ` Andrey Konovalov
2025-02-20 16:32 ` Andrey Konovalov
2025-02-21 14:44 ` Maciej Wieczor-Retman
2025-02-22 15:06 ` Andrey Konovalov
2025-02-25 15:39 ` Maciej Wieczor-Retman
2025-02-20 2:49 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+fCnZcDyS8FJwE6x66THExYU_t_n9cTA=9Qy3wL-RSssEb55g@mail.gmail.com' \
--to=andreyknvl@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dennis@kernel.org \
--cc=dvyukov@google.com \
--cc=dwmw@amazon.co.uk \
--cc=glider@google.com \
--cc=guoweikang.kernel@gmail.com \
--cc=hpa@zytor.com \
--cc=jan.kiszka@siemens.com \
--cc=jason.andryuk@amd.com \
--cc=jgross@suse.com \
--cc=jhubbard@nvidia.com \
--cc=julian.stecklina@cyberus-technology.de \
--cc=justinstitt@google.com \
--cc=kaleshsingh@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kbingham@kernel.org \
--cc=kees@kernel.org \
--cc=kevinloughlin@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kuan-ying.lee@canonical.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=luto@kernel.org \
--cc=maciej.wieczor-retman@intel.com \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=pankaj.gupta@amd.com \
--cc=pasha.tatashin@soleen.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=richard.weiyang@gmail.com \
--cc=rppt@kernel.org \
--cc=ryabinin.a.a@gmail.com \
--cc=samuel.holland@sifive.com \
--cc=scott@os.amperecomputing.com \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=thiago.bauermann@linaro.org \
--cc=thomas.weissschuh@linutronix.de \
--cc=tj@kernel.org \
--cc=tony.luck@intel.com \
--cc=vincenzo.frascino@arm.com \
--cc=vitalybuka@google.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
--cc=xur@google.com \
--cc=ytcoode@gmail.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox