All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.