Re: How to access an applications ELF program header and ELFsection header at runtime

[Bharath Ramesh <bramesh at vt dot edu>]

On Tue, Jan 05, 2010 at 12:56:30AM +0100, Petr Baudis wrote:
>   Hi!
> 
> On Mon, Jan 04, 2010 at 04:03:31PM -0500, Bharath Ramesh wrote:
> > On Fri, Oct 23, 2009 at 11:02:55AM -0400, Carlos O'Donell wrote:
> > > On Thu, Oct 22, 2009 at 4:49 PM, Bharath Ramesh <bramesh@vt.edu> wrote:
> > > > I am trying to play around with the symbols __data_start and __bss_start
> > > > to access the location of the .data and .bss section. Is there any way I
> > > > need to typecast these symbols so that I can get the information from
> > > > these symbols.
> > > 
> > > extern const char __symbol __attribute__((weak));
> > > #define symbol ((unsigned long)&__symbol)
> > > 
> > 
> > As mentioned in earlier emails to this thread [1] I need to access the
> > .data and .bss sections of an application. I need to access this from
> > the constructor of my shared library. I am not of the reason, but I am
> > an unable to get access to __data_start. It always has a value of NULL
> > address to it. I am able to get valid value for _edata, __bss_start and
> > _end. When I use nm to list the symbols of the application __data_start
> > does exist with an offset, but __data_start symbol for the shared
> > library doesnt have any offset. Is there something I am missing, is
> > there any way I can make sure that I get the valid address for these
> > symbols from the constructor of the shared library.
> 
>   I think these symbols correspond just to the sections in your local
> ELF object, not in the main program; furthermore, there can be multiple
> such sections in the ELF object, and all sorts of other hairy issues.

That was my first thought that the symbols I am getting correspond to my
ELF object. The offset of these symbols returned in fact match the
applications offset and not the shared library's.

> 
>   I think you are seriously best off just parsing /proc/self/maps, which

I was trying to avoid exactly this of parsing /proc/self/maps. I guess
for now that will be the current solution until I can think of or find a
better way.

> will give you up-to-date and complete information; you will probably
> want to sync all PROT_WRITE mappings. Note that the mappings can change
> over time - the heap will grow with brk()/sbrk(), new objects will be
> linked in with dlopen(), mappings will come and go by mmap(), mremap()
> and munmap()... and that's all I can think of, there might be more but
> if you cover for these calls, you should probably cover most of the
> cases...
> 
>   ...except it might be impossible to hijack mmap() calls inside glibc
> (e.g. in malloc() ;-).  I would say you have three reasonable (and
> several unreasonable) choices: ptrace()ing your application to pick out
> offending syscalls, patching the kernel to notify you about mapping
> changes, or restricting your project to indeed support only static
> storage synchronization and disallow dlopen().

I can avoid this scenario as I have my own implementation of malloc
which lets me select where I want to place the heap and how I want to
grow it. I do not plan on supporting new objects being linked with
dlopen or the application directly calling mmap(), mremap() or munmap()
for now. Those are probably something that I might explore in the
future.

Most importantly, thank you for taking time out to reply to my query.

Regards,

Bharath

Attachment: smime.p7s
Description: S/MIME cryptographic signature