On Fri, Aug 24, 2018 at 10:21:08AM -0600, Theo de Raadt wrote: > Scott Cheloha <[email protected]> wrote: > > > [...] > > > > I'm hunting this code because it mentions "no sysctl" as its raison > > d'etre, which is definitely not a reason for keeping it. > > It is confusing that it says sysctl (rather than syscall). I don't see > how SIGSYS gets delivered for a subset of sysctl, it is only delivered > for a whole syscall being missing. Maybe this is an attempt at > supporting ABI-crossing from the CSRG days, from before sysctl, to when > sysctl was added, and then the code remained behind for other reasons?
Here is the diff where it first appeared: https://svnweb.freebsd.org/csrg/sbin/init/init.c?r1=58422&r2=58421&pathrev=58422 Apparently added to gracefully handle the case where sysctl(2) caused SIGSYS if they failed to retrieve or set the kernel security level. I think. KERN_SECURELVL itself was introduced only a few days prior: https://svnweb.freebsd.org/csrg/sys/sys/sysctl.h?r1=58329&r2=58328&pathrev=58329 And KERN_SECURELVL only became available via sysctl like a half hour prior to the /sbin/init commit adding support for it: https://svnweb.freebsd.org/csrg/sys/kern/kern_sysctl.c?r1=58415&r2=58414&pathrev=58415 sysctl itself was introduced only a month before all of this: https://svnweb.freebsd.org/csrg/sys/kern/kern_sysctl.c?r1=57843&r2=57842&pathrev=57843 ... so your theory makes sense. > These days we have far more experience at ABI crossings, and are > providing better solutions (seeing as we've adjusted/broken/changed the > ABI only oh hundreds of times..)
