Log ENOSYS in init

[brooks]

Summary

While rare, encountering an unimplemented system call early in init is
catastrophic and difficult to debug. Even after a SIGSYS handler is
registered, such configurations are problematic. As such, always log
such events for pid 1.

[brooks]

I ran into this on a CHERI system where we've added new revocation related system calls used in malloc. Unfortunately, we call malloc in strdup even before the (rather questionable) badsys hander is installed. Due to someone changing the kernel configs and me not noticing I lost a half day to not having those syscalls...

[imp]

badsys is a piece of work...

[kevans]

It might not be a bad idea to make it (p->p_pid == 1 && (kern_lognosys & 3) == 0) -- kern.lognosys is RWTUN, so one could theoretically have chosen an explicit behavior in loader or static kenv and that should probably be followed. OTOH, with the current check, the behavior's OK:

kern.lognosys=0: Log to console
kern.lognosys=1: Log to both
kern.lognosys=2: Log to console
kern.lognosys=3: Log to both

Obviously the only one that would change is lognosys=1 to keep the message on ctty only. Either way, I agree that it should be logged even if it's explicitly set to 0 and don't insist on the above at all.

sys/kern/kern_sig.c

3798 ↗

(On Diff #76514)

As an aside, it'd be nice to document the values for lognosys somewhere or differently; as far as I can tell, they're only documented in the commit message of rS321627.

[brooks]

• Honor kern.lognosys if non-zero.