From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20044 invoked by alias); 6 Oct 2006 20:33:55 -0000 Received: (qmail 20032 invoked by uid 22791); 6 Oct 2006 20:33:54 -0000 X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Oct 2006 20:33:45 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k96KXhbB002961; Fri, 6 Oct 2006 16:33:43 -0400 Received: from pobox.hsv.redhat.com (pobox.hsv.redhat.com [172.16.16.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k96KXcXY013837; Fri, 6 Oct 2006 16:33:38 -0400 Received: from [172.16.17.170] (dhcp-170.hsv.redhat.com [172.16.17.170]) by pobox.hsv.redhat.com (8.12.8/8.12.8) with ESMTP id k96KXb1e029366; Fri, 6 Oct 2006 16:33:37 -0400 Message-ID: <4526BD8F.3060002@redhat.com> Date: Fri, 06 Oct 2006 20:33:00 -0000 From: David Smith User-Agent: Thunderbird 1.5.0.7 (X11/20061004) MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: systemtap@sources.redhat.com Subject: Re: precompiled probing scenarios References: <20061006190806.GA30553@elastic.org> In-Reply-To: <20061006190806.GA30553@elastic.org> Content-Type: text/plain; charset=us-ascii; 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-q4/txt/msg00042.txt.bz2 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)