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. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
