Re: Multiple instances of libc (ELF shared object)

[Arthur Gold <agold at bga dot com>]

[Chris: I hope you don't mind the email response]

I was taking an approach somewhat similar to this--i.e. just brute force
copying of code to some safe place--and it works fine, but only for true
system calls (IOW write and mprotect were fine). The problem has come
with the need to segregate wrappers that are more substantial (well, not
a _whole_ lot more substantial, but more substantial nevertheless) like
sigprocmask(). In Linux i386 (my primary platform, though platform
independence--for some value of independence--is the real goal),
sigprocmask() ends up using bzero to clean out a buffer and ultimately
calls __syscall_sigprocmask() which is the wrapper for the straight
system call. Solaris does it differently, as I suspect *BSD might as
well.

My current proposed solution is to assemble a shared object containing
the functions I need to segregate that links in libc statically, using
the --wrap directive in ld for those particular functions to avoid
polluting the namespace (this is all to be part of a shared object that
will be a preloaded library). My hope is that this will give me the
control I need to make sure that names don't 'leak through' to the
application.

Actually, there's something even somewhat prinipled in all this! As most
of the work of a tracing module is done in signal handlers, only 'safe'
(i.e. non malloc()-ing, non libc state-mutating functions should even be
available! 

Damn I hope this gives me what I need!
(Can someone say 'true module system'?)

Comments?

Many thanks.
--ag

[BTW, my ISPs news feed seems a little strange; this reply just popped
up today]

Chris Torek wrote:
> 
> In article <37FE4E5A.E2F54AF8@bga.com> Arthur Gold  <agold@bga.com> wrote:
> >... to trace library access. In order to do this, we protect the
> >pages containing the library's code and data and notice (and fix) the
> >seg faults that occur. The problem, of course, is that if you protect
> >the page containing mprotect(), you've locked the keys in the car! (and
> >if you just punt and _not_ protect that page, you lose accuracy in the
> >trace)...
> >In addition, we do _not_ want to notice accesses that occur in the
> >tracing code itself (i.e. while the faults are being handled). hence the
> >conundrum.
> 
> A much-less-head-achey way to do this is to enumerate all of the
> calls you want to make directly, then write those yourself using
> some *other* name:
> 
>                 .global __trace_mprotect
>         __trace_mprotect:
>                 push    $SYS_mprotect
>                 chmk
>                 bcc     0f
>                 negl    $1,r0
>         0:      ret
> 
>                 .global __trace_write
>         __trace_write:
>                 push    $SYS_write
>                 chmk
>                 bcc     0f
>                 negl    $1,r0
>         0:      ret
>         /* etc */
> 
> Assemble your new system call stubs and call *those* functions from
> your trace code.  Once you have done that, only those functions
> whose names do *not* fit your special, easily-recognized pattern
> (here __trace_*) get traced.
> 
> (Note that you may need to learn the local assembly language and
> system call conventions.  The above are sort of a vague approximation
> to ones for the VAX, just so that no one will try to use them directly.)
> --
> In-Real-Life: Chris Torek, Berkeley Software Design Inc
> El Cerrito, CA  Domain: torek@bsdi.com  +1 510 234 3167
> http://claw.bsdi.com/torek/  (not always up)    I report spam to abuse@.

-- 
Artie Gold, Austin, TX
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--
Pet peeve: "its" = belonging or pertaining to "it" | "it's" = "it is"