Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch

[Jakub Jelinek <jakub@redhat.com>]

On Fri, Jan 30, 2004 at 04:17:08AM +0000, Jamie Lokier wrote:
> Ulrich Drepper wrote:
> > > As this is x86, can't the syscall routines in Glibc call directly
> > > without a PLT entry?
> > 
> > No, since this is just an ordinary jump through the PLT.  That the
> > target DSO is synthesized is irrelevant.  It's ld.so which needs the PIC
> > setup, not the called DSO.
> 
> I have not explained well.  Please read carefully, as I am certain no
> indirect jumps on the userspace side are needed, including the one
> currently in libc.
> 
> It is possible to compile, assemble and link a shared library with
> -fno-PIC on x86, and this does work.  I just tested it to make sure.
> Furthermore, the "prelink" program is effective on these libraries.

Only if there are no prelink conflicts in the read-only sections.
Furthermore, there is additional overhead of remapping RW and back RX
and wasted page.  You can get around that by making a RWX section (which
ends up in the RW segment which gets a PF_X bit set as well), but that means
all the data in that segment is executable, which is obviously not
desirable, especially for libc.so.

> I'm talking about the "prelink" program.  When you run "prelink" on a
> libc.so which has direct jump instructions as described above, is
> patches the libc.so file to contain the address of the kernel entry
> point at the time "prelink" was run.

Prelink ATM doesn't take VDSO into account at all and surely it would
be best if it did not have to.  For example if VDSO is randomized, userspace
has no control over its placement like it has for shared libraries
(if DSO base is NULL, kernel randomizes, if non-NULL (usually means
prelinked), then does not randomize unless the binary is PIE).

	Jakub