Re: [patch 0/3] Live PIDs with deleted files by /dev/PID/mem

[Mark Wielaard <mjw at redhat dot com>]

On Wed, 2014-02-26 at 18:27 +0100, Jan Kratochvil wrote:
> On Wed, 26 Feb 2014 17:42:26 +0100, Mark Wielaard wrote:
> > I'll try and understand what I was trying to do,
> > clean it up and post it, if it looks useful/sane.
> 
> OK, I think we can talk about it even in abstract.

I figured out what was going on and posted some patches to fix some
issues with elf_from_remote_memory that hopefully help understand things
better.

> The primary problem of bfd_from_remote_memory (bfd/elfcode.h) always IMO was
> that it does not know the valid range of memory addresses belonging to the ELF
> file.

I didn't know BFD does something similar. Is that just for ELF or does
BFD handle multiple formats from memory?

>  elf_from_remote_memory seems to share this problem.

Yes, it doesn't know for sure how and where the dynamic linker will have
placed the ELF loadable segments. But given an ELF image load address
and the phdrs it will be possible to know which file ranges have been
mapped to which segments using the phdr PT_LOADs. It does need match how
the dynamic loader handles the PT_LOADs.

> So while I did not remember elf_from_remote_memory could be applicable in this
> case in the end I still find the current solution of replacing
> elf_from_remote_memory logic by reading ELF boundaries from /proc/PID/maps
> instead as more safe/reliable.

Combining elf_from_remote_memory with the /proc/PID/maps addresses would
certainly make this more robust (and it would probably have caught the
alignment issue quicker). But I think using elf_from_remote_memory does
(now) also give the valid ranges on its own.

Lets see how to combine the approaches most effectively.
I'll try and cleanup my patch to linux-proc-maps.c to make it possible
to use elf_from_remote_memory for "(deleted)" files to make it easier to
test things out.

Cheers,

Mark