linux-kernel - Re: [PATCH v2 01/14] kasan: sw_tags: Use arithmetic shift for shadow computation

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <qacbgkfbfqylupmoc7umy4n5pdvpdp7hrok7hqefhamhrsnhhm@4e2qucovduw2>
Date: Thu, 13 Mar 2025 15:56:00 +0100
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: Andrey Konovalov <andreyknvl@...il.com>
CC: Vitaly Buka <vitalybuka@...gle.com>, <kees@...nel.org>,
	<julian.stecklina@...erus-technology.de>, <kevinloughlin@...gle.com>,
	<peterz@...radead.org>, <tglx@...utronix.de>, <justinstitt@...gle.com>,
	<catalin.marinas@....com>, <wangkefeng.wang@...wei.com>, <bhe@...hat.com>,
	<ryabinin.a.a@...il.com>, <kirill.shutemov@...ux.intel.com>,
	<will@...nel.org>, <ardb@...nel.org>, <jason.andryuk@....com>,
	<dave.hansen@...ux.intel.com>, <pasha.tatashin@...een.com>,
	<guoweikang.kernel@...il.com>, <dwmw@...zon.co.uk>, <mark.rutland@....com>,
	<broonie@...nel.org>, <apopple@...dia.com>, <bp@...en8.de>,
	<rppt@...nel.org>, <kaleshsingh@...gle.com>, <richard.weiyang@...il.com>,
	<luto@...nel.org>, <glider@...gle.com>, <pankaj.gupta@....com>,
	<pawan.kumar.gupta@...ux.intel.com>, <kuan-ying.lee@...onical.com>,
	<tony.luck@...el.com>, <tj@...nel.org>, <jgross@...e.com>,
	<dvyukov@...gle.com>, <baohua@...nel.org>, <samuel.holland@...ive.com>,
	<dennis@...nel.org>, <akpm@...ux-foundation.org>,
	<thomas.weissschuh@...utronix.de>, <surenb@...gle.com>,
	<kbingham@...nel.org>, <ankita@...dia.com>, <nathan@...nel.org>,
	<ziy@...dia.com>, <xin@...or.com>, <rafael.j.wysocki@...el.com>,
	<andriy.shevchenko@...ux.intel.com>, <cl@...ux.com>, <jhubbard@...dia.com>,
	<hpa@...or.com>, <scott@...amperecomputing.com>, <david@...hat.com>,
	<jan.kiszka@...mens.com>, <vincenzo.frascino@....com>, <corbet@....net>,
	<maz@...nel.org>, <mingo@...hat.com>, <arnd@...db.de>, <ytcoode@...il.com>,
	<xur@...gle.com>, <morbo@...gle.com>, <thiago.bauermann@...aro.org>,
	<linux-doc@...r.kernel.org>, <kasan-dev@...glegroups.com>,
	<linux-kernel@...r.kernel.org>, <llvm@...ts.linux.dev>, <linux-mm@...ck.org>,
	<linux-arm-kernel@...ts.infradead.org>, <x86@...nel.org>
Subject: Re: [PATCH v2 01/14] kasan: sw_tags: Use arithmetic shift for shadow
 computation

On 2025-03-07 at 02:10:39 +0100, Andrey Konovalov wrote:
>On Tue, Mar 4, 2025 at 3:08 PM Maciej Wieczor-Retman
><maciej.wieczor-retman@...el.com> wrote:
>>
>> But looking at the patch you sent I'm wondering - are we treating the arithmetic
>> in kasan_mem_to_shadow() as unsigned?
>
>The shift is signed (arithmetic). But for the addition, it doesn't
>matter? Adding an integer to a void* pointer should result in the same
>value, regardless of whether the integer is signed or unsigned.

Yes, you're right, sorry.

>
>> You wrote that all the ranges will
>> overflow but I thought we're interpreting the arithmetic as signed - so only
>> positive addresses will overflow and negative addresses (with bit 63 set) will
>> only be more negative thus not causing an overflow.
>
>Ah, yes, I see what you mean. From the C point of view, calculating
>the shadow address for a pointer with bit 63 set can be interpreted as
>subtracting from KASAN_SHADOW_OFFSET, and there's no overflow. But on
>the assembly level, the compiler should generate the add instruction,
>and the addition will overflow in both cases.
>
>The important thing is that both possible shadow memory ranges are
>contiguous (either both start and end overflow or none of them).
>
>So this was my brain converting things to assembly. Feel free to
>reword/clarify the comments.

Right, I focused too much on the signed aspect. Treating everything as
overflowing sounds better, more unified.

>
>> That was my assumption when
>> writing the previous checks - we need to check below the overflown range, above
>> the negative (not overflown) range, and between the two.
>
>It could be that your checks are equivalent to mine. What I did was to
>check that the address lies outside of both contiguous regions, which
>makes the checks symmetrical and IMO easier to follow.

I drew this out and yeah, it looks like it's the same, just grouping the logical
expressions differently. What do you think about incorporating something like
the following into your comment about the x86 part? :

	Given the KASAN_SHADOW_OFFSET equal 0xffeffc0000000000
	the following ranges are valid mem-to-shadow mappings:

	0xFFFFFFFFFFFFFFFF
		INVALID
	0xFFEFFBFFFFFFFFFF - kasan_mem_to_shadow(~0UL)
		VALID	- kasan shadow mem
		VALID	- non-canonical kernel virtual address
	0xFFCFFC0000000000 - kasan_mem_to_shadow(0xFEUL << 56)
		INVALID
	0x07EFFBFFFFFFFFFF - kasan_mem_to_shadow(~0UL >> 1)
		VALID	- non-canonical user virtual addresses
		VALID	- user addresses
	0x07CFFC0000000000 - kasan_mem_to_shadow(0x7EUL << 56)
		INVALID
	0x0000000000000000

-- 
Kind regards
Maciej Wieczór-Retman