On Fri, Aug 24, 2018 at 10:02:21AM -0600, Theo de Raadt wrote: > Scott Cheloha <[email protected]> wrote: > > > The badsys() function has been here since import. Its comment > > indicates that SIGSYS might arrive if the system doesn't support > > sysctl, which is not applicable to us anymore, if ever. > > > > The only legitimate case I can think of here, now, is the desire > > to support dropping an old init(8) onto a new kernel and not having > > the box panic immediately if it calls an obsolete syscall. > > > > But that isn't something we support, no? And if the kernel ABI is > > changing such that init(8) is calling an obsolete syscall, there are > > steps one can take to migrate init(8) to the new ABI to prevent the > > situation. > > > > So SIGSYS should cause a disaster() exit upon first receipt like > > all the other signals we haven't defined behavior for. > > Back in the old days (before horses had horseshoes), upgrades with > bsd.rd or other hot-plug media were far from trivial. If the ABI > changed, you wanted init to "limp" towards starting a single-user shell > at least, otherwise you were prevented from next steps towards crossing > the ABI bump by replacing init... > > I can see your argument that this isn't needed anymore.
I mean, if there are nasty situations where you're trying to bring up a fubar'd box where getting init to exec the single-user shell makes or breaks your efforts, then I can just update the comment to indicate this. Do such situations occur anymore (anyone reading please chime in)? Even if rarely, that's still legit. I'm hunting this code because it mentions "no sysctl" as its raison d'etre, which is definitely not a reason for keeping it.
