Re: [patch] validate binary before use

[Jan Kratochvil <jan.kratochvil@redhat.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