This has bothered me since I first ran bsmconv on Solaris 2.3.
People are using performance as a reason not to enable auditing on their systems,
and it has been hard to convince them as there are no hard metrics to look at.
With Solaris 10 I was given the solution to the problem - DTrace. Since the day I first read about it I thought that I'd write this script, but since it never have been something I've truly needed in my job, until now, I've put it off.
Yesterday I started to write on a script, and it was easier than I thought it would, but on the other hand, I know much more about DTrace and the gory details of the auditing magic in the kernel than I did when first looked at this about two years ago.
Once I've fine-tuned the script I'll publish it,
but until I've worked out all the quirks I'll just post some results for the execve system call:
the average execution time for the 1066 execve syscalls I measured was 839 µs,
of those calls 419 were audited,
and the average time spent in the audit_start() function in the kernel was 1.8 µs,
and the average time spent in the audit_finish() function in the kernel was 13.5 µs.
The numbers above comes from using the vtimestamp to measure the time
spent in the
audit_start()
and
audit_finish()
functions in the c2audit
kernel module.
As you can see only about 1.8% of the time is spent in the auditing code, not very much!
Two things to note:
First the execve syscall is one of the slower,
so things will probably look different when I look at some of the faster ones.
Second this is not the whole truth.
When the c2audit kernel module is loaded,
it sets t_pre_sys and and t_post_sys on
klwp_t
and therefore pre_syscall() and post_syscall()
are executed in addition to audit_start() and audit_finish().
The above number does not include the other code in pre_syscall() and post_syscall() in the calculation,
which I need to include if I am going to measure the full impact of enabling auditing.
