| |||||||||||||
KHB: Dynamic Instrumentation of Production Systems (a.k.a. DTrace)KHB: Dynamic Instrumentation of Production Systems (a.k.a. DTrace)Posted Sep 21, 2006 11:00 UTC (Thu) by pharm (guest, #22305)Parent article: KHB: Dynamic Instrumentation of Production Systems (a.k.a. DTrace)
"A tracing system that can still cause the system to crash in some situations will be limited to kernel developers, students, and other people with the luxury of unscheduled downtime." Is it actually possible for a systemtap script to crash the kernel directly (without any embedded C in the script that is)? (trundles off to read the systemtap wiki). Hmm: The systemtap documentation does say: "In practice, there are several weak points in systemtap and the underlying kprobes system at the time of writing. Putting probes indiscriminately into unusually sensitive parts of the kernel (low level context switching, interrupt dispatching) has reportedly caused crashes in the past. We are fixing these bugs as they are found, and constructing a probe point blacklist, but it is not complete." I'll be willing to bet that DTrace had similar issues before public release though... The 'all-or-nothing' nature of dropping compiled code (script->C) straight into the kernel does mean that the code could do anything at all, which in turn means that system tap has to be root-only: DTrace can have more fine-graining access restrictions due to the in-kernel script interpreter. If they fix the 'can crash the system by tapping the wrong points' problems, then having the system tap script compiler be setuid and disallow embedded C for user-space scripts should allow the same kind of finer-grained permissions that DTrace allows (at the expense of the stap binary being a potential root-hole of course: the in-kernel interpreter will always be more secure).
(Log in to post comments)
|
|||||||||||||