This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: pre-compiled modules
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: David Smith <dsmith at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Mon, 19 Jun 2006 12:40:51 -0400
- Subject: Re: pre-compiled modules
- References: <1150298740.16471.33.camel@dhcp-2.hsv.redhat.com>
Hi -
dsmith wrote:
> I've been looking at pre-compiled modules, and in general they should
> work. I do have a few questions:
>
> 1) One thing I've been worried about is differing options between
> compile time and run time. I believe that most of them should be OK,
> with the exception of the '-b' relayfs option. If it was specified at
> compile time and not at run time (or vice versa), I'm not sure what will
> happen (since that flag appears to change behavior both at compile time
> and run time).
>
> Got any ideas here on how to prevent this?
One possibility would be to remove the run-time meaning of -b: don't
pass it to stpd any more. Perhaps the value could flow by/within the
module to the runtime to stpd at run time. Perhaps the
stp_check/mount check could be deferred until late in the module
initialization sequence. Martin?
> 2) Pre-compiled systemtap modules work, but there are a couple of things
> we could/should theoretically check for:
>
> 2a) Correct kernel version. Right now there is nothing to prevent a
> user from compiling a systemtap script into a module against kernel X,
> rebooting his system, then trying to run the module against kernel Y.
>
> From what I've been looking at, there really isn't a good way to check
> this, except for calling "modprobe --dry-run".
>
> Do you know of a better way? Do you think this check is necessary?
Blatant modversions mismatches will be detected during the actual
insertion attempt - IMO there is no need to make a dry run first. We
will need more self-protective code though for purposes of verifying
module addresses. Specifically, we need to find a kernel API routine
that, given a module name, gives its loaded base address.
> 2b) Actually a systemtap module. Currently there is nothing preventing
> a user from telling systemtap to run a pre-compiled module that is a
> valid kernel module, but isn't a systemtap module. I'm unsure of what
> might happen here.
>
> A way to check for this would to somehow check for the existence of a
> systemtap specific symbol, such as systemtap_module_init, before running
> the module.
>
> Got any ideas on a good way of doing that? Is it necessary?
At this point, only a privileged user can run stap, so the risks are
already unlimited in a sense, though mitigated by the fact that
harmful loadable .ko's are rarely found lying idly around.
- FChE