This is the mail archive of the
mailing list for the elfutils project.
Re: [PATCH 2/2] libdwfl: elf_from_remote_memory only trust shdrs of last file-only segment.
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 10 Mar 2014 21:27:54 +0100
- Subject: Re: [PATCH 2/2] libdwfl: elf_from_remote_memory only trust shdrs of last file-only segment.
On Thu, 2014-03-06 at 22:19 +0100, Jan Kratochvil wrote:
> On Mon, 03 Mar 2014 15:31:28 +0100, Mark Wielaard wrote:
> > If the last PT_LOAD segment that contains the whole shdrs also extends
> > the segment in memory beyond the end of file the program might be reusing
> > the memory space that we expect the shdrs to be in. Don't trust the shdrs
> > are valid in that case.
> Could there be a reproducer for it?
> The "deleted executable eu-stack" works for me even without this patch
> (for both sleep and firefox).
> It is not obvious to me in which case this exception is needed.
Normally we either get all of the shdrs or can easily detect that the
end of the ELF file (where the shdrs are normally located) doesn't fall
completely in the last segment mapped in. The exception is needed only
in some corner cases that are not that common (basically when the
sections have been reordered in such a way that a NOBITS one falls at
the end of the last PT_LOAD segement).
The reproducer I have here is libxul.so on RHEL6 (the one from
firefox-24.3.0-2.el6_5.x86_64 specifically. It has been processed by
https://wiki.mozilla.org/Elfhack. Which places the .bss at the end. The
issue comes from the fact that the last PT_LOAD segment has a memsize
that is larger than the filesize. That is because the last section
covered by that segment is .bss. So where normally (when filesize ==
memsize) the end of the segment mapped in might contain the shdrs, in
this case the end will be overwritten by data that the program might be
using for things not mapped in from the file.
This does indeed not impact the pure unwinding itself. That is because
dwarf_getcfi_elf will use getcfi_phdr if getcfi_shdr fails. So
the .eh_frame data will be found anyway, even if the shdrs aren't
complete. But it won't work for dwfl_module_build_id. Which will only
use phdrs if there are no shdrs (if there are shdrs the file could be a
debuginfo file, for which the phdrs cannot be trusted, so it cannot
easily fall back to phdrs). Without buildid the debuginfo cannot be
found, even if it is installed on the system.