From: "Frank Ch. Eigler" <fche@redhat.com>
To: Jovi Zhang <bookjovi@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, jovi.zhangwei@huawei.com
Subject: Re: [RFC] ktap: Another dynamic tracing tool for Linux
Date: Thu, 17 Jan 2013 22:35:57 -0500 [thread overview]
Message-ID: <20130118033557.GE13185@redhat.com> (raw)
In-Reply-To: <CACV3sbKYPUSOsccptgyJtaEp4Oxx6yX0XgVEEa+BfTPLpD28qA@mail.gmail.com>
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
next prev parent reply other threads:[~2013-01-18 3:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-31 3:32 [RFC] ktap: Another dynamic tracing tool for Linux Jovi Zhang
2012-12-31 18:58 ` Frank Ch. Eigler
2013-01-04 8:13 ` Jovi Zhang
2013-01-04 15:19 ` Frank Ch. Eigler
2013-01-18 1:24 ` Jovi Zhang
2013-01-18 3:35 ` Frank Ch. Eigler [this message]
2013-01-18 4:02 ` Jovi Zhang
[not found] <917750116.79371357913957820.JavaMail.root@srv11.zimbra.polymtl.ca>
[not found] ` <422821122.79411357913979039.JavaMail.root@srv11.zimbra.polymtl.ca>
2013-01-13 3:50 ` Jovi Zhang
[not found] <68461756.264831358192004350.JavaMail.root@srv11.zimbra.polymtl.ca>
2013-01-14 19:39 ` Michel Dagenais
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130118033557.GE13185@redhat.com \
--to=fche@redhat.com \
--cc=bookjovi@gmail.com \
--cc=jovi.zhangwei@huawei.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox