[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87seya452v.fsf@>
Date: Wed, 22 May 2024 10:35:20 +0200
From: Nicolai Stange <nstange@...e.de>
To: Kees Cook <keescook@...omium.org>
Cc: Jeremy Linton <jeremy.linton@....com>, Arnd Bergmann <arnd@...db.de>,
"Gustavo A. R. Silva" <gustavoars@...nel.org>,
linux-hardening@...r.kernel.org, Elena Reshetova
<elena.reshetova@...el.com>, Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] randomize_kstack: Improve entropy diffusion
Kees Cook <keescook@...omium.org> writes:
>
> diff --git a/include/linux/randomize_kstack.h b/include/linux/randomize_kstack.h
> index 5d868505a94e..6d92b68efbf6 100644
> --- a/include/linux/randomize_kstack.h
> +++ b/include/linux/randomize_kstack.h
> @@ -80,7 +80,7 @@ DECLARE_PER_CPU(u32, kstack_offset);
> if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, \
> &randomize_kstack_offset)) { \
> u32 offset = raw_cpu_read(kstack_offset); \
> - offset ^= (rand); \
> + offset = ror32(offset, 5) ^ (rand); \
Hi Kees,
I'm wondering whether this renders the per-arch mask applied to 'rand'
at the respective choose_random_kstack_offset() invocations ineffective?
Like e.g. on x86 there is
choose_random_kstack_offset(rdtsc() & 0xFF);
I would argue that while before the patch kstack_offset had been
guaranteed to stay within the bounds of 0xFF, it's now effectively
unlimited (well, <= (u32)-1) and only capped to 0x3ff when subsequently
applying the KSTACK_OFFSET_MAX().
Or am I simply missing something?
Thanks!
Nicolai
> raw_cpu_write(kstack_offset, offset); \
> } \
> } while (0)
--
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
GF: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Powered by blists - more mailing lists