Re: precompiled probing scenarios

[David Smith <dsmith@redhat.com>]

Frank Ch. Eigler wrote:
> Hi -
> 
> Here are some ideas about pre-compiled probes.  It all tries to bring
> together some concepts we've kicked around about caching,
> pre-compilation, remote deployment, run-time probe parametrization,
> and the stap/staprun split.

This is certainly ambitious.

> One part of the plan would be a cache of compiled probe modules.
> Unless disabled, the translator would compute a hash of the probe
> script and environmental parameters (e.g.  sess.kernel_release,
> architecture, invoking userid).  This hash value would be used to
> identify the module in a persistent cache
> ($HOME/.systemtap/cache/HASH.ko just like ccache), so that the same
> script for the same machine would map to the same module name.  (A
> person deliberately running the same script twice concurrently would
> have to "salt" the cache/hash for the duplicates.)  A "stap -p4" run
> would print the cached module's file name.

Hmm.  Are we hashing the input script?  If so, how does this work with 
probe wildcards?  For example, let's say I probe "kernel.function("*")". 
  We compile and cache this module.  I then plug in a bunch of 
additional hardware, which causes several extra modules to be loaded.  I 
then run stap again with the exact same input script.  If the cached 
module gets run, the functions in the new modules won't be probed.

It seems to me that the cached version of a script should probe the 
exact same functions as a newly compiled version would.

> To run a compiled probe, one would normally use "staprun HASH.ko".
> Since we already support parametrization (extra module parameters can
> initialize string/number global script variables), staprun should be
> extended to pass those on to insmod.  (By the way, as we discussed,
> staprun will be extended to send a variant of /proc/modules to the
> module, so it can relocate its module probes.)

A minor point here.  Currently, staprun expects to be run as root, so if 
you aren't root, you've got to run "sudo staprun HASH.ko".

> Cross-compilation could come in by letting users specify a target name
> for probing.  This name would be mapped to a kernel version,
> architecture, cpu type, and maybe a build-root, all via a
> configuration file $HOME/.systemtap/known_hosts.  (A host may have
> multiple target names, for example for different kernel versions.)
> The translator might update its own host's details to that file
> automatically, so a network-wide file could be grown by running the
> translator once on each client machine and concatenating the files.

Wow.  Supporting different kernel versions on the same arch/cpu is 
currently supported.  Doing different arch/cpu types is going to be 
difficult.  There has been a big discussion on 
fedora-devel-list@redhat.com fairly recently about cross-compilation (I 
can try to dig up links if needed), but I don't recollect if there was a 
concrete plan developed.  We've got it a bit easy in that the kernel is 
self-contained and doesn't need a C library, etc.

> Once such a cross-compiled module is built, it could be saved in the
> local cache (-p4), and for -p5 even shipped to a named remote machine
> via scp and executed there via ssh/staprun.  (Probing several remote
> machines concurrently could be easily accomodated.)
> 
> We've mentioned somehow securely identifying of compiled modules to
> represent a special permission to execute.  This would be a way of
> having a security expert dude formally designate a module for use on a
> locked-down deployment machine.  Given that the modsign code in
> FC/RHEL is not widespread or general enough, a proper kernel-enforced
> crypto signature may be out of reach.  Maybe we can list (say) md5sums
> of approved module .ko's in a /etc/systemtap/authorized_probes file,
> and have a new staprun.auth variant that checks it before submitting a
> module to insmod(8) (or actually better, to sys_init_module(2)
> directly).

Hmm.  Is this new staprun.auth variant a setuid program or does the user 
still need sudo privileges?

-- 
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)