Messages in this thread |  | | Date | Fri, 18 Jan 2013 12:02:06 +0800 | Subject | Re: [RFC] ktap: Another dynamic tracing tool for Linux | From | Jovi Zhang <> |
| |
On Fri, Jan 18, 2013 at 11:35 AM, Frank Ch. Eigler <fche@redhat.com> wrote: > Hi - > > On Fri, Jan 18, 2013 at 09:24:55AM +0800, Jovi Zhang wrote: >> Let us continue this ktap topic in this thread :). >> ktap code is public available at github, please clone from: >> https://github.com/ktap/ktap.git >> [...] > > Neat stuff. I have one set of initial observations: even with a nice > small bytecode language, the VM has to be skeptical and careful. For > example, some dangers: > > - any dynamic memory allocation from within the context of an > arbitrary tracepoints (table_* functions, stack frames) > - unchecked arithmetic (division-by-zero - OP_DIV, overflows, > function arity limits) > - time-quantity of computation (limit loop iterations / #-bytecodes?, > DO_JMP infinite loops) > - stack-frame usage of interpreter (if internally recursive, or if > too much state kept on stack) > - trusting validity of bytecode (imagine an attacker sending random > or harmful junk, jumping out of bytecode ranges) > - calls out from interpreter into native code - to ensure that *all* > those functions (transitively) are valid to call from general > e.g. tracepoint context (e.g. sleeps often aren't) > - (and these problems get even worse with evaluation from the > context of kprobes) > > > - FChE
Yeh, that's why this code is called initial implementation. most of dangers you pointed I have thought about, most of them should not have too much hard to solve it, it just need some time, some of them already listed in Todo-list.txt.
Thanks your quick observations, the comments is valueable, and need to be address step by step in future development (I also think most issues is very common for script dynamic tracing tool, not specific for ktap, but ktap have to go through those barrier one by one)
Let's waiting for ktap official release 0.1, the code quality would be more better than now :)
.jovi
|  |