Re: [patch] validate binary before use

[Aleksandar Ristovski <aristovski at qnx dot com>]

On 13-04-05 07:47 AM, Jan Kratochvil wrote:
> 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.

Correct.

> 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.

It is stored in the latest patch, in build-id.

> > 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.

See my comment 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.


What I am suggesting is that linux-nat (and any other *-nat) should 
implement TARGET_OBJECT_LIBRARIES_SVR4.


> 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.


Exactly, see above.


> 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

I don't think you are following me, but hopefully my comments above 
clarify it.


> > 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