Audit Kernel Events, weekly report #4

[Efstratios Karatzas]

Hello, this is the long overdue weekly report.

Last couple of weeks I kept busy with university exams so there wasn't
much progress. My obligations will end pretty soon and I'll be able to
focus on my gsoc project.

new stuff:

- Finished support for nfsv2&3 in the new experimental nfs server;
everything seems to be working tip top.

- Updated my wiki page. I've 'deleted' the milestones that are done
and I changed the timeline because I'm still waiting for some feedback
on my ideas for 'audit & multiple record handling', from my mentor.
If anyone is interested, I've also included a link to a small demo of
my code: contains a shell script that triggers most of the nfs rpcs &
the audit log that is being produced. Please refer to the wiki page
for more info
http://wiki.freebsd.org/SOC2010EfstratiosKaratzas

- Also, I figured out why and when vn_fullpath() kernel-panicked in my
code, after applying my old patches. If this point is reached, while
we 're holding an exclusive lock on the vnode, the system will kernel
panic with a exhaustive->shared situation:
http://fxr.watson.org/fxr/source/kern/vfs_cache.c#L1096
Triggering this kernel panic can be done easily -again, with my old
patches- if we: start the nfs server, the client mounts a filesystem
and gets valid file handles, the server reboots and the client
requests some operation -> No hints in namecache, we resort to
VOP_VPTOCNP() and try to lock the vnode, boom. My current code is
immune to this bug because I make sure that no locks are held when the
two vn_fullpath KPIs are called.

I'm taking the time to write all this because I think that the man
page should be updated to reflect this new possible bogus behavior.
Since RELENG_8, VOP_VPTOCNP() is called from vn_fullpath code and
vn_fullpath() itself is used quite a few times in the kernel and some
times, the caller holds a lock to the vnode.
http://www.freebsd.org/cgi/man.cgi?query=vn_fullpath

I've already started reading up on NFSv4 and compound RPCs and over
the next week, I'll be working towards providing audit support for
NFSv4 in the new experimental nfs server. After this is done, just
before midterm evaluations (I hope), I'll start working on my last
remaining milestone: making Audit framework handle multiple
simultaneous audit records per kernel thread.

As always, any input is much appreciated.

Ta ta

-- 

Efstratios "GPF" Karatzas