Re: patch: VFS: fix passing of AT_PHDR value in auxv to ELF interpreter

[Quentin Godfroy <godfroy@clipper.ens.fr>]

On Fri, May 04, 2007 at 09:24:05PM -0700, Jeremy Fitzhardinge wrote:
> > Indeed, I haven't seen that. For ET_DYN executables, it could be done a
> > thing like load_addr+elf_ppnt->p_vaddr (in the function that creates the
> > auxv, as ity has access to the elf header), and for ET_EXEC do what I
> > propose. I think this is trivial to do. I'll do it as soon as I come back
> > in front of my machine.
> >   
> 
> I don't think you need to special-case it.  You can compute the offset
> between the linked address and the load address (first
> PT_LOAD[0]->p_vaddr - load_addr) and use that to offset all the other
> addresses.

Indeed. And it has the advantage to work for prelinked objects. (but I
have to understand anyway how does the kernel handles prelinked (or not) pie
executables)

> 
> 
> > I don't understand. Yes it is what it is supposed to be, and the kernel
> > is supposed to give the vaddr of the phdr table to the interpreter and
> > not load addr + offset of phdr in file, which is sometimes wrong.
> >   
> 
> How can it be wrong?  Does the PT_PHDR point to a different array of
> Phdr entries?

No, of course, but in my case I wanted to build an executable with a
modified rpath. I had to add a new PT_LOAD segment. To do so, as the
program header is generally located at the very beginning of the
executable, I had to copy it to the end, and so the address where it was
loaded was completely different.

The load address was typically 0x08048000, and the phdr location was
0x0804a570. But the kernel gave to the ld.so in the auxv the addr
0x08048570 for the phdr. And it provoked a segfault because of the .bss
which was between the segments. (and even if there was no .bss, it would
have worked only by chance because the segments could all fit in a page
of 4kb)

Quentin