This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] validate binary before use
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Aleksandar Ristovski <aristovski at qnx dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 5 Apr 2013 13:47:32 +0200
- Subject: Re: [patch] validate binary before use
- References: <512E42D1 dot 3040101 at qnx dot com> <514C58B2 dot 6090701 at qnx dot com> <20130328183727 dot GA14798 at host2 dot jankratochvil dot net> <515B0632 dot 1040502 at qnx dot com> <20130402165306 dot GA9479 at host2 dot jankratochvil dot net> <515B12D1 dot 7050505 at qnx dot com> <20130403180917 dot GA6102 at host2 dot jankratochvil dot net> <515CDF7F dot 5020403 at qnx dot com> <20130404081302 dot GA4099 at host2 dot jankratochvil dot net> <515D7A09 dot 5010305 at qnx dot com>
On Thu, 04 Apr 2013 15:03:05 +0200, Aleksandar Ristovski wrote:
> The problem is, we could 'remember' build-id that is garbage.
Where/how?
In gdbserver mode gdbserver sends really the build-id of target library.
Therefore at GDB so_list->build_id - if set - is also always right (for the
target side). GDB then uses elf_tdata (so->abfd)->build_id for the comparison
which is also always right on the GDB side.
In solib-svr4 mode GDB uses target_read_memory for an address found from the
symbol file. This may read a garbage but that garbage is never stored
anywhere, it is only local variable in svr4_validate_build_id. It compares it
with elf_tdata (so->abfd)->build_id which is always right for the symbol file.
> I will
> add checking for GNU\0 and note type, and then the likelihood that
> somewhat random memory will match namesz, name and type will be very
> low (though the likelihood has nothing to do with the 160 bits of
> build-id; build-id is not necessarily 160 bits either).
I do not understand this paragraph after my reply above.
> The rest is about design and duplicated functionality. The
> functionality of gdbserver where it fetches the list is exactly the
> same what -nat can do;
I was talking about linux-nat to differentiate it from gdbserver. But in fact
the non-gdbserver (local) patchset part is in solib-svr4.c, not linux-nat.c.
Only that commonly when one uses the local part of solib-svr4.c one is using
linux-nat.c that time - but one could be using for example sparc-sol2-nat.c
instead.
As discussed before solib-svr4.c is not Linux-specific, therefore it does not
and cannot read /proc/PID/maps. Therefore it cannot find the ELF header
without getting a help from the symbol file (which will give the address
difference between ELF header and DYNAMIC segment which we know from l_ld).
At least I have never found a way how to reliably find the ELF header from
link_map entry without having an associated symbol file.
This is why gdbserver (using linux-low.c which IS Linux specific) situation is
very different from the non-gdbserver local (using solib-svr4.c which is
OS-independent) situation.
Sure one could make a Linux-specific local solib-*.c backend but the current
plan is to drop all (in reality just some) *-nat.c files in the favor of
always using gdbserver.
> in fact this could be the same code;
Really could not, see above. The local solib-svr4.c mode should not exist but
it unfortunately still needs to be kept live as gdbserver is not fully
feature-by-feature matching linux-nat.c:
http://sourceware.org/gdb/wiki/LocalRemoteFeatureParity
> Not to be neglected is that by doing so, it would be possible to
> look for the debug binary directly, by using build-id instead of
> opening objfile and then looking for separate_debug_fie.
Unfortunately could not.
Thanks,
Jan