[RFC PATCH v1 2/2] randomize_kstack: Unify random source across arches
Mark Rutland
mark.rutland at arm.com
Tue Dec 2 02:02:20 PST 2025
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 at arm.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 at arm.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.
More information about the linux-arm-kernel
mailing list