This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pre-compiled modules


How about save the meta data (stap compile options, kernel version, location for .ko etc...) at compile time then load the pre-compiled module via 'stap metadata.file'

Hien.

Frank Ch. Eigler wrote:
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]