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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <t5bgb7eiyfc2ufsljsrdcinaqtzsnpyyorh2tqww2x35mg6tbt@sexrvo55uxfi>
Date: Fri, 21 Mar 2025 20:20:51 +0100
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: Andrey Konovalov <andreyknvl@...il.com>
CC: Florian Mayer <fmayer@...gle.com>, 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>, <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 2025-02-26 at 16:24:28 +0100, Andrey Konovalov wrote:
>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.

After adding this option the kernel doesn't want to boot past uncompressing :b

I went into Samuel's clang PR [1] and found there might be one more LShr that
needs changing into AShr [2]? But I'm not very good at clang code. Do you maybe
know if anything else in the clang code could be messing things up?

After changing that LShr to AShr it moves a little further and hangs on some
initmem setup code. Then I thought my KASAN_SHADOW_OFFSET is an issue so I
changed to 4-level paging and the offset to 0xfffffc0000000000 and it moves a
little further and panics on kmem_cache_init. I'll be debugging that further but
just thought I'd ask if you know about something missing from the compiler side?

[1] https://github.com/llvm/llvm-project/pull/103727
[2] https://github.com/SiFiveHolland/llvm-project/blob/up/hwasan-opt/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp#L995

-- 
Kind regards
Maciej Wieczór-Retman