linux-kernel - LTTng-UST bytecode interpreter

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

Message-ID: <808977110.11119.1413628312625.JavaMail.zimbra@efficios.com>
Date:	Sat, 18 Oct 2014 10:31:52 +0000 (UTC)
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Alexei Starovoitov <ast@...mgrid.com>
Cc:	linux-kernel@...r.kernel.org,
	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>
Subject: LTTng-UST bytecode interpreter

Hi Alexei,

Following our Plumbers discussion, here are links to
lttng-ust and lttng-tools parts that are relevant to
the bytecode I use for tracepoint filtering:

http://git.lttng.org/?p=lttng-tools.git;a=summary
src/lib/lttng-ctl/filter/*.[ch]
  -> parser of filter expressions to AST, then to
     intermediate representation, followed by
     bytecode generation.

The bytecode is then moved from the client to the
application being traced through the lttng-sessiond
daemon.

http://git.lttng.org/?p=lttng-ust.git;a=summary
liblttng-ust/lttng-filter.c:
  filter "linker" attaching bytecode to tracepoint.
  _lttng_filter_event_link_bytecode() has all the
  steps required to translate a bytecode into
  something the interpreter can use.

liblttng-ust/lttng-filter-specialize.c:
  Perform type specialization of some opcodes. This
  is done after linking to an event fields, now that
  we know their type.

liblttng-ust/lttng-filter-validator.c
  Validation of the bytecode: making sure typing is
  consistent, checks there are no loops (no backward
  jump).

liblttng-ust/lttng-filter-interpreter.c
  Bytecode interpreter, executes quickly without any
  checks, relying on the fact that they were already
  performed by the validator. It is a threaded
  interpreter which has 2 registers aliasing the top
  of its stack.

My general approach is to use an interpreter to deal
with the general case, which makes porting to new
architectures easy. We can then have JIT phases if
we want to eventually translate this bytecode into
native instruction.

Working with a bytecode which has a slightly higher
level semantic allows dealing with strings as a basic
type in addition to integers and floating point values.

Please note that the current bytecode is limited to
64-bit integers. We can eventually extend it to be
more compact (8, 16, 32-bit integers).

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
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/