[lkml]   [2013]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] ktap: Another dynamic tracing tool for Linux
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:
> [...]

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

 \ /
  Last update: 2013-01-18 05:01    [W:0.055 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site