>> Wouldn't it be better to fix them all, by making ktracers find out
>> about data the kernel reads from places pointed to by syscalls?
> I had ideas about this, but it would be a bit intrusive.

Yes, it would.  It just seems like the Right Thing to me.

> Working at the syscall code level seems unworkable, because you don't
> know if the argument given to the syscall will actually be used.

Worse, you sometimes don't know how much data it points to, or whether
that data itself contains pointers which are followed, etc.

> IMO the right place to trace things is at copyin/copyout level:

I agree.  That is where I would attack it if I were to try to do this.
And this is why I think "intrusive" is an appropriate word; finding and
touching all the code that does copyin/copyout or related calls would
be a major project.

In this case, though, I wouldn't want this best to be the enemy of the
good.  In my own experience, sysctl is not the biggest offender; that
dubious honour probably belongs to connect() - it is impossible to tell
where a connection attempt is to from just the ktrace.  But that's not
to say that improving sysctl is a bad thing.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B