Re: [patch] validate binary before use

[Aleksandar Ristovski <aristovski at qnx dot com>]

On 13-02-01 03:04 PM, Jan Kratochvil wrote:
> On Fri, 01 Feb 2013 15:31:27 +0100, Aleksandar Ristovski wrote:
> > On 13-01-31 10:06 PM, Jan Kratochvil wrote:
> > > This behavior is correct.  Changing it would break all the tools around.
> >
> > <offtopic>
> > If you say so. IMO it is less than ideal, it should specify l_addr
> > as expected and make prelink transparent. Like this, it special
> > cases meaning of this field, which is common and across many systems
> > happens to always have the same meaning (except when 'successful'
> > prelinking happens).
> > </offtopic>
>
> FYI on gdbserver/linux-low.c get_phdr_phnum_from_proc_auxv finds PHDR_MEMADDR
> which is the absolute L_ADDR form you ask for.
>
> Just solib-svr4.c tries to be (is it?) cross-OS compatible so it does not have
> this PHDR_MEMADDR value available.


<still-offtopic>
To avoid any misunderstanding: I am not emotional about this topic at 
all. Take what follows as a light-weight hallway conversation over a coffee:

I will not claim familiarity with how linux works, but auxv typically 
has information for the executable only, not the shared objects (i.e. 
auxv is the "connecting link" between process loader and dynamic linker 
- interpreter). For shared objects, however, this can not be used 
because the information is not there. Dynamic linker does not add 
anything to auxv nor does auxv have entries for e.g. load base of any of 
the shared objects.

To be clear: I am very familiar with how this works on Neutrino and the 
preceding and following claims come from that and *not* from gnu/ld 
familiarity. If it's different on gnu/linux, let me know.

Using auxv is fairly os-agnostic as long as an os is svr4-like. 
solib-svr4.c uses auxv via target_auxv_search, nothing wrong with that. 
But again, this applies to exe only. Auxv does not have any information 
about arbitrary shared objects executable links against - that is 
entirely ld's business and not process loader's.

Therefore, the only clue for deterministic and straight forward 
relocation calculus for a tool like gdb is l_addr from the link map. If 
gnu ld is not setting it up when "successful prelink" happens it is 
making a mistake: 0 load base may be legitimate and true in some cases 
on some systems. Furhter, it unnecessary introduces this difference when 
it would probably change very little (nothing?) if it set it up 
correctly to what the load base really is, just as it does for 
"unsuccessful" prelinks or non-prelinked objects.
</still-offtopic>