On Sat, 18 Feb 2023, Michael Schmitz wrote: > Am 18.02.2023 um 12:49 schrieb Finn Thain: > > On Sat, 18 Feb 2023, Andreas Schwab wrote: > > > >> On Feb 18 2023, Finn Thain wrote: > >> > >>> Why do you say init ignores SIGABRT? > >> > >> PID 1 is special, it never receives signals it doesn't handle. > >> > > > > I see. I wonder if there is some way to configure the kernel so that > > PID 1 could be aborted for fstack-protector. I doubt it. > > You could add SIGABRT to the list of signals handled by init (see > init.c:init_main() and init.c:process_signals() in the sysvinit source). > > Not sure it's wise to allow init to abort though. You could instead try > to use a similar signal handler to segv_handler(), and dump core when > receiving the signal? Maybe re-exec init instead of continuing? >
I like the idea of patching the kernel so as to log every SIGABRT sent (even if never delivered), ideally along with the target pid and cmd and the sending pid and cmd. > > > > My gut says that a compiler change somehow made the fstack-protector > > implementation insensitive to kernel configuration. > > > > So I still think that, if Stan adopted Debian's build environment, > > random processes would cease to be aborted (regardless of kernel > > .config). > > Changes in compiler version between sysvinit 3.01 and 3.06 might cause a > bisect using snapshot binaries and a bisect using recompiled binaries to > differ. > According to the buildd logs: package | compiler ---------+----------- 3.01-1 | 11.2.0-12 3.02-1 | 11.2.0-19 3.03-1 | 11.2.0-19 3.04-1 | 12.1.0-7 3.05-7 | 12.2.0-7 3.06-2 | 12.2.0-10 Those debs are all available on https://snapshot.debian.org/package/sysvinit/ in case Stan wants to bisect. No need to build anything. > But using a build environment equivalent to that used by the package > autobuilders is certainly good advice. > > Or did you mean the kernel build environment? > I meant the kernel build environment which was a double-think on my part as it isn't really relevant here.
