[Integrit-devel] Re: DL?

[Ed L C. <ec...@co...>]

Sasha <sa...@ye...> writes:

> Ed,
> 
> 	Forgive me if I am slightly uninformed, but, I was going to
> suggest that you actually consider using the ELF dynamic module interface
> for integrit if you want to cut down on memory usage.  Does it really need
> components like the hashtbl stuff when it's sitting idle, not accessing
> any cdb databases?  If not, why not unload them?  There are relatively few
> functions involved.  It could turn out very elegantly if you had a go at
> it, I think.  
>
> I could help implement them, I am very familiar with the dl*() interface.

That's an interesting suggestion.  I've broken my response into
sections, since my response is getting long.

No Big Win
----------

While that appeals to the perfectionist in me, it violates the
simplicity that is the second design goal of integrit.  

It's true that it might help with the first goal: namely, a small
memory footprint, but that goal has already been achieved, so I don't
think that any extra complexity is justified.

To address a specific point, the hashtbl stuff is the most used stuff
in the whole package, so loading and unloading it makes no sense.  The
hashtbl stuff is unrelated to the cdb stuff: it's used to store the
rule sets from the configuration file, so for each file, you need to
do a hashtbl lookup for each level of the file's path to see whether
the user has specified special options for the file or the directories
above it.

But since this is C and not C++, there are no really big parts of the
code that could be a big win to unload.  e.g., If the user doesn't
specify the XML switch, then you could unload all the XML stuff, but
that's only 97 lines of code!

(It would be more simple for me to make the XML DTD a configure
option, so that those 34 lines of code would be left out when people
didn't request that integrit produce a DTD.  -- It's literally dead
weight right now.  ... I put it on the todo list.)

Portability
-----------

I'm concerned that the dl*() stuff may be less portable, since it's
newer.  e.g., What about people running FreeBSD 3.0 with a.out?

Also, if the interface isn't perfectly consistent across platforms, it
would be detrimental to the maintainability of integrit, again with
little gains.

Static Linking and Install Complexity
-------------------------------------

There's another issue I'd be concerned about, since I'm not too
familiar with the dl*() interface.  integrit must be statically
linked, since the shared libraries of the host are not known to be in
a trusted state.  

Will dynamic linking still work?  If so, then are multiple files
necessary instead of one integrit binary?  If so, then the extra
complexity for the user is unacceptable, since it's already hard
enough to do something like tripwire or integrit, where you have to
install a trusted binary somewhere secure.

Real-World Criterium: Performance
---------------------------------

That said, your suggestion is still really interesting.  Could you
recommend some good resources for learning the interface?  Maybe you
have some example code or test code to share?  I'd like to learn
about it.

If it's an easy thing to do the dl*() stuff, then you or I would have
to do all this just to see whether there's any real-world advantage to
making the change:

   using the latest integrit 
   (cvs is at http://sourceforge.net/cvs/?group_id=15369)

   implement dl*() stuff

   run benchmarks to show that there's a big gain in performance

   create easy-to-read patches with 
   diff -cr integrit integrit-dl > integrit-dl.diff

... but if it's not easy, then it's probably not worth the trouble,
unless one of us is just looking for a fun thing to do.  :)

-- 
--Ed Cashin                     PGP public key:
  ec...@co...           http://www.coe.uga.edu/~ecashin/pgp/