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 17:42 +0100, Mark Wielaard wrote:
> On Wed, 2014-02-26 at 17:37 +0100, Jan Kratochvil wrote:
> > On Wed, 26 Feb 2014 17:29:38 +0100, Mark Wielaard wrote:
> > > I got something somewhat working some time back, but I don't understand my
> > > own patches... (most are really just lots of extra debug output).
> > 
> > And are those patches posted somewhere?
> 
> No they are just in an old branch here mixed with lots of random looking
> debug printfs in one big commit. It doesn't even compile at the moment.
> Just a quick experiment last month to see if it would work (it kind of
> did, but not really). I'll try and understand what I was trying to do,
> clean it up and post it, if it looks useful/sane.

It took a bit of time to understand what I was struggling with. The
reason was because it really was two somewhat subtle bugs that had
somewhat the same symptoms, so fixing only one did seem to work
somewhat, but not fully.

First the elf_from_remote_memory used the p_align value to see calculate
the file offset and sizes of the segments in memory. But the dynamic
loader doesn't p_align, it uses the actual pagesize, which is often, but
not always, smaller than the p_align value. This caused the code to
overestimate the parts of the file that was mapped into memory. This
lead to pread sometimes mysteriously failing (if the extra memory wasn't
actaully available). But more often the memory was available and the
code thought that it had more of the file available than there really
was, leading to hilarious issues while for example trying to parse the
shdrs.

Which brings us to to the second issue. Even with the above fixed the
shdrs might look like they were mapped in, but then the memory would be
reused by the program. Trying to parse the wrong shdrs would make us
fail to find the build-id making things much less useful than could be
if we would have just assumed the shdrs weren't there and gotten the
build-id from the phdrs. To detect this situation we can check whether
the segment only contains mapped file contents. If the segment extends
the memory beyond it file size (maybe because it is adds bss at the end)
we shouldn't trust the shdrs even if we think they were mapped in
because the program might just see it as random data it can reuse.

I'll sent the patches to the list and add them to mjw/pending.

Cheers,

Mark