On Wed, Jun 20, 2012 at 1:40 AM, Andres Perera <[email protected]> wrote: > sorry, but i never sold nm as the sole step granting immunity. i > explicitly presented it as an example. nevertheless, the full list of > things i do do not cover all of possible changes you pointed out. i > constructed it in a way that also works with snapshots: > > diff include/sys/syscall{args,}.h with previous db (a la sysmerge); > double check with with nm /bsd. syscallargs changing returns false > whether or not nm shows the same set of calls. > > (i don't currently diff /sys/* in hopes of finding new or changed bitmap flags)
i am talking about include/sys, not the kernel source repository > > diff include/sys/ioctl.h and header-includes with previous db. i don't > attempt to detect new includes, this is fragile and is covered by > acting on sys/* > > the rest of files are predictable sets of other kernel apis. i don't > look at net/pfvar or anything outside sys even though i should > > as flaky as it can be, it works most of the time and it's better than > "let the user decide" > > On Wed, Jun 20, 2012 at 12:59 AM, Matthew Dempsky <[email protected]> wrote: >> On Tue, Jun 19, 2012 at 9:34 PM, Andres Perera <[email protected]> wrote: >>> all of the calls in syscalls.master map to a unique function, and all >>> of them start with sys_. it's true that nm won't tell me about >>> argument changes. i just risk it a little by assuming no one's that >>> evil >> >> Okay, granted nm will tell you when new syscall entry points get >> added... but you won't know about new syscall flags, new ioctls, new >> device nodes, new sysctls, new behavior, etc. >> >> Not saying you can't use nm as a backup sanity check, but it's not >> something I'd recommend relying on by default. Our userland is really >> not designed to run on older kernels.
