linux-kernel - Re: [RFC PATCH v1 2/2] randomize_kstack: Unify random source across arches

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: <aS65LFUfdgRPKv1l@J2N7QTR9R3>
Date: Tue, 2 Dec 2025 10:02:20 +0000
From: Mark Rutland <mark.rutland@....com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Ryan Roberts <ryan.roberts@....com>, Kees Cook <kees@...nel.org>,
	Ard Biesheuvel <ardb+git@...gle.com>, Will Deacon <will@...nel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Jeremy Linton <jeremy.linton@....com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	"Jason A . Donenfeld" <Jason@...c4.com>,
	linux-hardening@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 2/2] randomize_kstack: Unify random source across
 arches

On Tue, Dec 02, 2025 at 10:47:04AM +0100, Ard Biesheuvel wrote:
> On Tue, 2 Dec 2025 at 10:35, Mark Rutland <mark.rutland@....com> wrote:
> > On Tue, Dec 02, 2025 at 10:15:22AM +0100, Ard Biesheuvel wrote:
> > > On Mon, 1 Dec 2025 at 19:20, Ryan Roberts <ryan.roberts@....com> wrote:
> > > > I've got bot warnings because this is being called from noinstr code. I guess
> > > > the best option is to just move add_random_kstack_offset() to after
> > > > instrumentation is enabled for the affected arches.
> > >
> > > Just put instrumentation_begin()/instrumentation_end() around the call
> > > to prandom_u32_state() - that seems to be the common approach for
> > > punching holes into the 'noinstr' validation.
> >
> > That silences the warning, but isn't necessarily safe, so please DO NOT
> > do that blindly.
> 
> Oops - sorry about that.

No problem! I just wanted to make sure we didn't start to gain broken
usage that'd need an audit and cleanup.

[...]

> Given that prandom_u32_state() does a fairly straight-forward mangle
> of 4 32-bit words, might it be better to make that __always_inline
> itself?

Possibly! I don't know whether it's better to have prandom_u32_state()
inline or out-of-line.

So long as prandom_u32_state() doesn't call out to instrumented code,
making it an __always_inline function will be safe.

Mark.