Re: stack smashing detected
Finn,
On 2/17/23 4:49 PM, Finn Thain wrote:
> 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.
>
> 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).
>
What's interesting to me is that although there are stack smashing
errors and "aborted" messages during boot, nothing seems to have
actually failed or aborted (note that no processes are named as
"terminated" or "aborted" in the messages). Once logged in, I can't
duplicate the stack smashing (yet), and I don't see random executables
failing. The stack smashing seems to happen only in startup scripts that
have heavy access to /proc (the mountkernfs script seems particularly
vulnerable, as I recall), though none of the scripts seems to actually fail.
I'm not a programmer, but I'm willing to learn. I don't know what
Debian's build environment is, or how to adopt it or set it up, but I
can look into it with some suggestions. My goal as a user was simply to
have small current kernels that boot in a reasonable time on slow
33-year-old hardware with limited memory, and that goal has been
achieved (3.5 MB kernel for PB 170, 4.8 MB kernel for other Mac 68030)
with no modules, no initrd, and custom init scripts that make Debian
look much more like NetBSD, or UNIX from the 90s. I'm also willing to
help track down any issues that involve real hardware, which is what I'm
trying to do here.
Reply to: