[Bug runtime/15665] New: idea: investigate fuzz testing for systemtap

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15665

            Bug ID: 15665
           Summary: idea: investigate fuzz testing for systemtap
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com

I am inspired by the bug-finding success of Trinity:
http://codemonkey.org.uk/projects/trinity/

I think there are at least two ways we could apply this to SystemTap.

1. Fuzz test the stap module interface, primarily the debugfs control file.  We
don't have specific syscalls, so Trinity itself might not be directly
applicable, but the idea of fuzzing input (in a focused way) certainly could
apply.  We apply different levels of trust to messages from staprun (setuid
root) versus stapio (running as user), so it makes more sense to me to fuzz
messages as the latter, representing some badly-behaving or even rogue stapio.

2. Fuzz test with Trinity while some representative SystemTap scripts are
running, especially with the syscall tapset where Trinity will be most active. 
This way we might find what unusual system activity will do to us -- hopefully
nothing!


Stepping completely away from Trinity, we might also try some controlled
fuzzing at stap's level, but bugs found there probably have less severity by
nature.  For instance, I find it unlikely that a fuzzed script would create
some issue that survives all the way to pass-5 and breaks in kernel mode.  (Not
counting guru snippets, as that's obviously breakable and thus not interesting
here.)  But fuzzing is all about revealing unlikely bugs, so it still may be
worth a shot.

-- 
You are receiving this mail because:
You are the assignee for the bug.