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)
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 <matt...@dempsky.org>
wrote:
> On Tue, Jun 19, 2012 at 9:34 PM, Andres Perera <andre...@zoho.com> 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.
