On 13.02.2025 23:00, Volodymyr Babchuk wrote: > Both GCC and Clang support -fstack-protector feature, which add stack > canaries to functions where stack corruption is possible. This patch > makes general preparations to enable this feature on different > supported architectures: > > - Added CONFIG_HAS_STACK_PROTECTOR option so each architecture > can enable this feature individually > - Added user-selectable CONFIG_STACK_PROTECTOR option > - Implemented code that sets up random stack canary and a basic > handler for stack protector failures > > Stack guard value is initialized in two phases: > > 1. Pre-defined randomly-selected value. > > 2. Own implementation linear congruent random number generator. It > relies on get_cycles() being available very early. If get_cycles() > returns zero, it would leave pre-defined value from the previous > step. > > Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> > Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> > --- > > Changes in v5: > > - Fixed indentation > - Added stack-protector.h
With this I question the retaining of Andrew's R-b. > --- /dev/null > +++ b/xen/common/stack-protector.c > @@ -0,0 +1,51 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include <xen/init.h> > +#include <xen/lib.h> > +#include <xen/random.h> > +#include <xen/time.h> > + > +/* > + * Initial value is chosen by a fair dice roll. > + * It will be updated during boot process. > + */ > +#if BITS_PER_LONG == 32 > +unsigned long __ro_after_init __stack_chk_guard = 0xdd2cc927UL; > +#else > +unsigned long __ro_after_init __stack_chk_guard = 0x2d853605a4d9a09cUL; > +#endif > + > +/* > + * This function should be called from early asm or from a C function > + * that escapes stack canary tracking (by calling > + * reset_stack_and_jump() for example). > + */ This comment is now stale, and ... > +void __init asmlinkage boot_stack_chk_guard_setup(void) ... I question the asmlinkage linkage here now, too. Based on how things are moving, I don't think this should be rushed into 4.20 (anymore). Jan
