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  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:	Sun, 24 Jan 2010 17:36:21 +0100 (CET)
From:	Thomas Gleixner <>
To:	"Frank Ch. Eigler" <>
cc:	Ingo Molnar <>,
	Linus Torvalds <>,
	Steven Rostedt <>,
	Fr??d??ric Weisbecker <>,
	Arnaldo Carvalho de Melo <>,
	Li Zefan <>,
	Tom Zanussi <>,,,
	Andrew Morton <>,
	Stephen Rothwell <>,
	Ananth N Mavinakayanahalli <>,
	Peter Zijlstra <>,
	Peter Zijlstra <>,
	LKML <>,,
	"H. Peter Anvin" <>,
Subject: Re: linux-next: add utrace tree

On Sat, 23 Jan 2010, Frank Ch. Eigler wrote:
> On Sat, Jan 23, 2010 at 07:04:01AM +0100, Ingo Molnar wrote:
> > [...]  Also, if any systemtap person is interested in helping us
> > create a more generic filter engine out of the current ftrace filter
> > engine (which is really a precursor of a safe, sandboxed in-kernel
> > script engine), that would be excellent as well. [...]
> Thank you for the invitation.
> > More could be done - a simple C-like set of function perhaps - some minimal 
> > per probe local variable state, etc. (perhaps even looping as well, with a 
> > limit on number of predicament executions per filter invocation.)
> Yes, at some point when such bytecode intepreter gets rich enough, one
> may not need the translated-to-C means of running scripts.
> > ( _Such_ a facility, could then perhaps be used to allow applications access 
> >   to safe syscall sandboxing techniques: i.e. a programmable seccomp concept 
> >   in essence, controlled via ASCII space filter expressions [...]
> >   IMHO that would be a superior concept for security modules too [...]
> >
> > [...]  specific functionality with an immediately visible upside,
> > with no need for opaque hooks.
> This OTOH seem like rather a stretch.  If one claims that "opaque
> hooks" are bad, so instead have hooks that jump not to auditable C
> code but an bytecode interpreter?  And have the bytecodes be uploaded
> from userspace?  How is this supposed to produce "transparency" from
> the kernel/hook point of view?

Simply because the kernel controls which byte code is executed and has
control over the functionality behind it. That makes the hooks well
defined and transparent.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists