public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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