linux-kernel - Re: [PATCH 1/3] x86: mm: disable KMSAN instrumentation for physaddr.c

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: <a2e7b9a1-15ff-41c3-a6b9-bdab4ead904b@intel.com>
Date: Fri, 21 Jun 2024 09:40:25 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Alexander Potapenko <glider@...gle.com>
Cc: elver@...gle.com, dvyukov@...gle.com, dave.hansen@...ux.intel.com,
 peterz@...radead.org, akpm@...ux-foundation.org, x86@...nel.org,
 linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com,
 "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH 1/3] x86: mm: disable KMSAN instrumentation for physaddr.c

On 6/21/24 02:48, Alexander Potapenko wrote:
> Enabling CONFIG_DEBUG_VIRTUAL=y together with KMSAN led to infinite
> recursion, because kmsan_get_metadata() ended up calling instrumented
> __pfn_valid() from arch/x86/mm/physaddr.c.
> 
> Prevent it by disabling instrumentation of the whole file.

This does seem rather ad-hoc.  It's the same basic reason we have
"noinstr": code instrumentation infrastructure uses generally can't be
instrumented itself.

How hard would it be to make sure that kmsan_get_metadata() and friends
don't call any symbols that were compiled with -fsanitize=kernel-memory?

I do also think I'd much rather see __no_kmsan_checks on the functions
than doing whole files.  I *guarantee* if code gets moved around that
whoever does it will miss the KMSAN_SANITIZE_physaddr.o in the makefile.