From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16491 invoked by alias); 19 Jun 2006 16:48:44 -0000 Received: (qmail 16475 invoked by uid 22791); 19 Jun 2006 16:48:42 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS,TW_YF X-Spam-Check-By: sourceware.org Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 19 Jun 2006 16:48:34 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5JGmUBB020807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Jun 2006 12:48:30 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5JGmdtW095336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Jun 2006 10:48:39 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5JGmUfG002554 for ; Mon, 19 Jun 2006 10:48:30 -0600 Received: from [9.47.22.138] (dyn9047022138.beaverton.ibm.com [9.47.22.138]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5JGmT20002537; Mon, 19 Jun 2006 10:48:29 -0600 Message-ID: <4496D55D.1080307@us.ibm.com> Date: Mon, 19 Jun 2006 16:48:00 -0000 From: Hien Nguyen User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: David Smith , systemtap@sources.redhat.com Subject: Re: pre-compiled modules References: <1150298740.16471.33.camel@dhcp-2.hsv.redhat.com> <20060619164051.GP30867@redhat.com> In-Reply-To: <20060619164051.GP30867@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00653.txt.bz2 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 >