On Tue, Nov 14, 2000 at 08:59:49AM -0600, Jesse Pollard wrote:
> I (meaning me) would like the ability to audit every system call. (yes,
> this is horrendous, if everything is logged, but I want to be able to
> choose how much is logged at the source of the data, rather than at
> the destination. That would reduce the total data flood to what is
> manageable or desired.
Yes, you really need to control the logging at the source of the data. To do
that we need to use to use self modifying tricks as dprobes and GKHI does to
provide "fast unregistered hooks".
o with dprobes the hooks will be _absolutely_ zero cost if they're
unregistered but they're very costly (basically enter/exit kernel
for every hook) when they're registered (so they're ok if
your auditing doesn't happen all the time).
dprobe hooks also binds you to a certain binary image (not a generic
interface stable across different kernel binaries)
o GKHI provides fast unregistered hooks too, if implemented with
5 nops as suggested they will cost around 3 cycles when they're
unregistered, and they will provide good performance also when
they're registered (no enter/exit kernel as dprobes needs
to do) and you can control them via userspace without being dependent
on binary offsets (just like with every other hook we have in kernel
just now but with the difference that our current hooks aren't self
modifying so they adds branches also when they're unregistered so
they're bad for usages like syscall auditing). However bloating every
syscall with tons of GKHI hooks isn't possible either or it will become
a performance problem too eventually. It depends what you need exactly.
I'd say one GKHI hook per syscall shouldn't have measurable impact on
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 15 2000 - 21:00:26 EST