linux-kernel - Re: [PATCH] mm, kmsan: fix infinite recursion due to RCU critical section

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]

Date: Thu, 18 Jan 2024 13:22:37 +0100
From: Marco Elver <elver@...gle.com>
To: Charan Teja Kalla <quic_charante@...cinc.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Alexander Potapenko <glider@...gle.com>, 
	Dmitry Vyukov <dvyukov@...gle.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
	Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, syzbot+93a9e8a3dea8d6085e12@...kaller.appspotmail.com
Subject: Re: [PATCH] mm, kmsan: fix infinite recursion due to RCU critical section

On Thu, 18 Jan 2024 at 12:28, Charan Teja Kalla
<quic_charante@...cinc.com> wrote:
>
> May I ask if KMSAN also instruments the access to the memory managed as
> ZONE_DEVICE. You know this is not the RAM and also these pages will
> never be onlined thus also not be available in buddy.
>
> Reason for the ask is that this patch is introduced because of a race
> between pfn walker ends up in pfn of zone device memory.
>
> If KMSAN never instruments this, does it look good to you to have the
> KMSAN version of pfn_valid(), as being suggested by Alexander in the
> other mail.

It would be nice to avoid duplicating functions - both options have downsides:
1. Shared pfn_valid(): it might break for KMSAN again in future if new
recursion is introduced.
2. KMSAN-version of pfn_valid(): it might break if pfn_valid() changes
in future.

I suspect #1 is less likely.

What is your main concern by switching to rcu_read_lock_sched()?