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: <aanh34t7p34xwjc757rzzwraewni54a6xx45q26tljs4crnzbb@s2shobk74gtj>
Date: Tue, 4 Mar 2025 13:29:34 +0100
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: Andrey Konovalov <andreyknvl@...il.com>
CC: <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-01 at 01:22:46 +0100, Andrey Konovalov wrote:
>On Thu, Feb 27, 2025 at 1:33 PM Maciej Wieczor-Retman
><maciej.wieczor-retman@...el.com> wrote:
>>
>> Btw just out of curiosity on the topic. If we used a runtime specified kasan
>> offset, could the gdb script issue (not knowing the offset at compile-time) be
>> fixed by just exporting the value through sysfs?
>>
>> I know that in inline mode the compiler would still need to know the offset
>> value but I was curious if this approach was okay at least in outline mode?
>
>I think this would work, assuming that GDB can pick it up from sysfs.

One other question that came to me about how KASAN works, is there some
mechanism to prevent data races between two threads? In the compiler perhaps?

For example memory is de-allocated and shadow memory is poisoned but some other
thread was just about to do a shadow memory check and was interrupted?

I've read the kasan/vmalloc.c comments and from them I'd extrapolate that the
caller needs to make sure there are not data races / memory barriers are in
place.

-- 
Kind regards
Maciej Wieczór-Retman