Re: Hooking into Linux using the Linux Trace Toolkit

From: Crispin Cowan (crispinat_private)
Date: Wed Apr 18 2001 - 23:50:23 PDT

  • Next message: sharma ajay: "suscribe"

    Karim Yaghmour wrote:
    
    > Well ... as Greg pointed out, you can't expect things to be completely seamless.
    
    I conferred with Greg, and determined that we're saying the same thing, but I'm not
    saying it as well :-)
    
       * You can produce binary-only modules, but they are *very* particular to the
         kernel.
       * If you get a mis-match with the kernel, you have to re-compile the module, but
         not the kernel.  However, you need the kernel source code headers to get the
         module to compile.
    
    The difference here is that Karim's proposal requires re-compiling the kernel.
    
    
    > That being said ...
    >
    > I guess what I'm aiming for is to have a general option in the kernel config
    > where you'd have the following:
    > Kernel Hooking (y/n)
    >         LSM support (y/n)
    >         Trace support (y/n)
    >         XYZ support (y/n)
    
    ... and that appears tobe a proposal to substantially expand the scope of this
    project.
    
       * Architecturally, this coupling makes sense, because both tracing and security
         need extensive hooking.
       * Politically, it is much more questionable.  Linus said he would accept a security
         module abstraction.  He said nothing about a trace facility.
    
    I don't wanna risk the acceptability of the LSM project by expanding its scope.  If
    you (Karim) want to float this past Linus, I suggest that you ask him.  If he says
    yes, then I'm all in.
    
    I don't mean to be harsh.  Architecturally, it makes a lot of sense to combine thease
    features.  It is just politically difficult.  So really, if you can get Linus' buy-in,
    go for it.
    
    
    > > It's kind of off-topic for LSM, but could you comment briefly on how
    > > LTT compares to the Paradyn project at Wisconsin
    > > http://www.cs.wisc.edu/paradyn/  They have some kind of mechanism for
    > > dynamically patching binary running programs, and in this tech report
    > > http://www.cs.wisc.edu/paradyn/papers/dynopt.pdf claim to be able to do the
    > > same thing to a running Solaris kernel.  Their purpose is dyanamic performance
    > > profiling -> optimization.
    >
    > I'm not sure LTT actually compares to Paradyn. It seems to me that
    > the purposes are different. In LTT, the hooking portion is but a
    > small part of the whole toolset. We need the hooks to retrieve
    > meaningfull information about the system's behavior. The collected
    > information is then fed to the analysis tool which provides the
    > user with a view of the dynamic behavior of the system.
    
    That actually sounds kinda similar to Paradyn.
    
    
    > As you point out, Paradyn aims dynamic performance profiling and optimization.
    > But LTT isn't aimed at dynamic optimization. Instead, it is aimed at:
    > -Dynamic behavior reconstruction
    > -Performance measurement
    > -Synchronization-problem solving
    > -Security auditing
    > -Intrusion detection
    
    I think you bound "dynamic" to the wrong scope. Paradyn is about achieving performance
    optimization through performance modeling.  They do that through behavior
    reconstruction & performance measurement.  The "dynamic" part is to allow dynamic
    change of the parts of the program being profiled.
    
    Crispin
    
    --
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX Communications, Inc. http://wirex.com
    Security Hardened Linux Distribution:       http://immunix.org
    
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Wed Apr 18 2001 - 23:55:16 PDT