Kees Cook <keesc...@chromium.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)
