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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+fCnZdE+rVcoR-sMLdk8e-1Jo_tybOc7PtSp9K6HrP5BEv95g@mail.gmail.com>
Date: Fri, 7 Mar 2025 02:10:39 +0100
From: Andrey Konovalov <andreyknvl@...il.com>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.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 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.

> 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.

> 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.