linux-kernel - Re: [PATCH v2 13/14] x86: runtime_const used for KASAN_SHADOW

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+fCnZejp4YKT0-9Ak_8kauXDg5MsTLy0CVNQzzvtP29rqQ6Bw@mail.gmail.com>
Date: Wed, 26 Feb 2025 16:24:28 +0100
From: Andrey Konovalov <andreyknvl@...il.com>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>, Florian Mayer <fmayer@...gle.com>, 
	Vitaly Buka <vitalybuka@...gle.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, 
	ndesaulniers@...gle.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 13/14] x86: runtime_const used for KASAN_SHADOW_END

On Wed, Feb 26, 2025 at 12:53 PM Maciej Wieczor-Retman
<maciej.wieczor-retman@...el.com> wrote:
>
> After adding
>         kasan_params += hwasan-instrument-with-calls=0
> to Makefile.kasan just under
>         kasan_params += hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET)
> inline works properly in x86. I looked into assembly and before there were just
> calls to __hwasan_load/store. After adding the the
> hwasan-instrument-with-calls=0 I can see no calls and the KASAN offset is now
> inlined, plus all functions that were previously instrumented now have the
> kasan_check_range inlined in them.
>
> My LLVM investigation lead me to
>         bool shouldInstrumentWithCalls(const Triple &TargetTriple) {
>           return optOr(ClInstrumentWithCalls, TargetTriple.getArch() == Triple::x86_64);
>         }
> which I assume defaults to "1" on x86? So even with inline mode it doesn't care
> and still does an outline version.

Ah, indeed. Weird discrepancy between x86 and arm.

Florian, Vitaly, do you recall why this was implemented like this?

To account for this, let's then set hwasan-instrument-with-calls=0
when CONFIG_KASAN_INLINE is enabled. And also please add a comment
explaining why this is done.

[...]

> >What do you mean by "The alignment doesn't fit the shadow memory size"?
>
> Maybe that's the wrong way to put it. I meant that KASAN_SHADOW_END and
> KASAN_SHADOW_END aren't aligned to the size of shadow memory.

I see. And the negative side-effect of this would be that we'll need
extra page table entries to describe the shadow region?

[...]

> I think this was a false alarm, sorry. I asked Kirill about turning
> pgtable_l5_enabled() into a runtime_const value but it turns out it's already
> patched by alternative code during boot. I just saw a bunch more stuff there
> because I was looking at the assembly output and the code isn't patched there
> yet.

Great!