This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 3/3] Access deleted files by /dev/PID/mem


On Sat, 2014-02-22 at 22:09 +0100, Jan Kratochvil wrote:
> the core.  The testcase mostly comes from the former patch.
>
> > libdwfl/
> > 2014-02-22  Jan Kratochvil  <jan.kratochvil@redhat.com>
> > 
> > 	Access deleted files by /dev/PID/mem.
> > 	* dwfl_module.c (dwfl_report_module_pid): New function.
> > 	* dwfl_module_getdwarf.c (open_elf): Call __libdw_open_file_at_offset.
> > 	* libdwfl.h (dwfl_report_module_pid): New declaration.
> > 	* libdwflP.h (struct Dwfl_Module): New field pid.
> > 	(INTDECL (dwfl_report_module_pid)): New.
> > 	* linux-proc-maps.c (proc_maps_report): New variable first_high.
> > 	(proc_maps_report) (report): Possibly call dwfl_report_module_pid.

A few high-level questions/suggestions to help me better understand why
this works as it does.

- Could we reuse dwfl_pid () instead of adding another pid concept to
  struct Dwfl_Module? Then a user could just use dwfl_linux_proc_attach
  which might also help us get into the ptrace attach state if needed
  for reading /proc/PID/mem.

- If possible having the detection of whether to use direct file access
  or using a /proc/PID/mem mapping in the dwfl_linux_proc_find_elf 
  instead of in proc_maps_report would be nice. That way it can be used
  more generically as fallback for when direct file access fails for
  whatever reason.

- If you look at elf_from_remote_memory (as used to fetch the vdso if
  possible) you'll see that it tries to clean up the headers a bit (like
  zeroing out the shdr offset and size if it cannot be found). You might
  want to do the same for the mmaped image so that we don't even try to
  read the section headers if they aren't there (and possibly read
  garbage). It also tries to minimize the used/read memory by scanning
  the PT_LOAD segments. But your maximum_size calculation might be
  easier.

  Do note that I had trouble getting elf_from_remote_memory to work
  correctly for anything besides the vdso. If I remember correctly there
  were some alignment requirements that didn't work out in some cases
  while scanning the PT_LOAD segments. I'll look for my hacks to see if
  there is anything useful.

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]