Date: Sat, 26 Jun 2010 01:37:36 +0300 From: Efstratios Karatzas <gpf.kira@gmail.com> To: soc-status@freebsd.org Subject: Audit Kernel Events, weekly report #4 Message-ID: <AANLkTinGV--zU0AwvHjDlwaIoU_BGCCvLDI9U8URK82X@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinGV--zU0AwvHjDlwaIoU_BGCCvLDI9U8URK82X>