linux-kernel - Re: [RFC] ktap: Another dynamic tracing tool for Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACV3sbJqFzVVL6R9x2wtqMeAxpD93k7-LV38jXQr4h_NMeUjDg@mail.gmail.com>
Date:	Fri, 18 Jan 2013 12:02:06 +0800
From:	Jovi Zhang <bookjovi@...il.com>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, jovi.zhangwei@...wei.com
Subject: Re: [RFC] ktap: Another dynamic tracing tool for Linux

On Fri, Jan 18, 2013 at 11:35 AM, Frank Ch. Eigler <fche@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/