Re: [patch 03/18] entry: Provide [syscall_]enter_from_user_mode_randomize_stack()

On 2026-07-07 12:06, Thomas Gleixner wrote:
> Randomizing the syscall stack can only happen after state is established
> via enter_from_user_mode() or syscall_enter_from_user_mode(). The earlier
> it happens the better.
> 
> Provide two new macros to consolidate that:
> 
>   - enter_from_user_mode_randomize_stack()
> 	enter_from_user_mode();
> 	add_random_kstack_offset_irqsoff();
> 
>   - syscall_enter_from_user_mode_randomize_stack()
> 	enter_from_user_mode_randomize_stack();
> 	syscall_enter_from_user_mode_work();
>     
> to reduce boiler plate code.
> 
> Those are macros and not inline functions as the latter would limit the
> stack randomization scope to the inline function itself.
> 
Not directly related to this patchset, but still:

Can anyone *please* find out what the actual security requirements are for the
syscall randomization offset?

The original checkin, 39218ff4c625 ("stack: Optionally randomize kernel stack
offset each syscall") indicates that it is fundamental that the stack offset
is applied *after* pt_regs pushing, but that isn't documented anywhere in the
kernel sources as far as I can tell.

However, I have also come to understand that there are further, undocumented
constraints; at least at one point I was told that "the offset should not be
stored in memory while running in the kernel", which seems more than a bit odd.

This matters, because it creates a data dependency on exit. The original
checkin does call out that RDTSC timing is inappropriate if the user could
control it, but using a hardware CSPRNG like RDRAND (or its equivalent for
other architectures) would be feasible if it isn't in the critical path. If an
RDRAND - store sequence can be executed on entry, *after* the stack
adjustment, then the high latency of RDRAND can hopefully be very effectively
hidden by an OO CPU.

Incidentally, in case you are wondering "why doesn't each core get a dedicated
CSPRNG and hardware randomness generator, to avoid high latency", the answer
is pretty simple: a hardware random number source, regardless of the specifics
of the design, almost by definition violates the hardware design rules of any
digital design; after all, the design rules are designed to *eliminate* noise
(making the circuit behave as closely as physically possible to a realization
of the abstract digital circuit), whereas the very goal of a HWRNG source is
to *extract and amplify* quantum thermal noise. This means that considerable
chip area is consumed by a "keep-out zone", a designated "no man's land"
keeping the digital logic away from the noise source. This keep-out zone is
typically much, much larger than the noise source itself.

	-hpa