Re: [RFC] ktap: Another dynamic tracing tool for Linux
From: Jovi Zhang
Date: Thu Jan 17 2013 - 23:01:53 EST
On Fri, Jan 18, 2013 at 11:35 AM, Frank Ch. Eigler <fche@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/