Re: linux-next: add utrace tree

Re: linux-next: add utrace tree

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 21 Jan 2010, Frank Ch. Eigler wrote:
> 
> > Less passionate analysis would identify a long history of contribution by 
> > the the greater affiliated team, including via merged code and by and 
> > passing on requirements and experiences.
> 
> The reason I'm so passionate is that I dislike the turn the discussion was 
> taking, as if "utrace" was somehow _good_ because it allowed various other 
> interfaces to hide behind it. And I'm not at all convinced that is true.
> 
> And I really didn't want to single out system tap, I very much feel the same 
> way abotu some seccomp-replacement "security model that the kernel doesn't 
> even need to know about" thing.
> 
> So don't take the systemtap part to be the important part, it's the bigger 
> issue of "I'd much rather have explicit interfaces than have generic hooks 
> that people can then use in any random way".
> 
> I realize that my argument is very anti-thetical to the normal CS teaching 
> of "general-purpose is good". I often feel that very specific code with very 
> clearly defined (and limited) applicability is a good thing - I'd rather 
> have just a very specific ptrace layer that does nothing but ptrace, than a 
> "generic plugin layer that can be layered under ptrace and other things".

( I think to a certain degree it mirrors the STEAMS hooks situation from a 
  decade ago - and while there were big flamewars back then we never regretted 
  not taking the STREAMS opaque hooks upstream. )

> In one case, you know exactly what the users are, and what the semantics are 
> going to be. In the other, you don't.
> 
> So I really want to see a very big and immediate upside from utrace. Because 
> to me, the "it's a generic layer with any application you want to throw at 
> it" is a _downside_.

One component of the whole utrace/systemtap codebase that i think would make 
sense upstreaming in the near term is the concept of user-space probes. We are 
actively looking into it from a 'perf probe' angle, and PeterZ suggested a few 
ideas already. Allowing apps to transparently improve the standard set of 
events is a plus. (From a pure Linux point of view it's probably more 
important than any kernel-only instrumentation.)

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. Right now we support simple C-syntax expressions like:

   perf record -R -f -e irq:irq_handler_entry --filter 'irq==18 || irq==19'

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.)

( _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 [broken down into
  predicaments for fast execution], syscall driven and inherited by child 
  tasks so that security restrictions percolate down automatically.

  IMHO that would be a superior concept for security modules too: there's no 
  reason why all the current somewhat opaque security hooks couldnt be 
  expressed in terms of more generic filter expressions, via a facility that
  can be used both for security and for instrumentation. That's all what 
  SELinux boils down to in the end: user-space injected policy rules. )

The opaque hookery all around the core kernel just to push everything outside 
of mainline is one of the biggest downsides of utrace/systemtap - and neither 
uprobes nor the concept of user-defined scripting around existing events is 
affected much by that.

So lots of work is left and all that work is going to be rather utilitarian 
with little downside: specific functionality with an immediately visible 
upside, with no need for opaque hooks.

	Ingo

Re: linux-next: add utrace tree

[Frank Ch. Eigler]

Hi -

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?

- FChE

Re: linux-next: add utrace tree

[Thomas Gleixner]

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