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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Jan 2013 22:35:57 -0500
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Jovi Zhang <bookjovi@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, jovi.zhangwei@...wei.com
Subject: Re: [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:
> 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
--
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/