This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: ppc64 vDSO in mainline
- From: Steve Munroe <sjmunroe at us dot ibm dot com>
- To: Ulrich Drepper <drepper at redhat dot com>
- Cc: Alan Modra <amodra at bigpond dot net dot au>, Benjamin Herrenschmidt <benh at kernel dot crashing dot org>, libc-alpha at sources dot redhat dot com, Roland McGrath <roland at redhat dot com>
- Date: Fri, 25 Mar 2005 16:04:42 -0600
- Subject: Re: ppc64 vDSO in mainline
Ulrich Drepper <drepper@redhat.com> wrote on 03/24/2005 06:06:04 PM:
> Steve Munroe wrote:
> > I can see how randomized VDSO for platforms using
> > NEED_DL_SYSINFO/DL_SYSINFO_IMPLEMENTATION might prevent a virus
attacker
> > from using syscalls. But powerpc is a NEED_DL_SYSINFO_DSO only
> > implemention and so can't prevent anyone from using syscalls inline.
And I
> > don't see how calling gettimeofday is a security threat?
>
> It doesn't matter whether inline syscalls can be made. The issue is to
> avoid fixed addresses for code at all costs. Therefore the vDSO must be
> randomizable without cost. That has all been discussed, and Ben wrote
> the vDSO code to allow just that. The fact that it means a minimal
> amount of additional work in the users of the vDSO is not important.
> The code in the vDSO doesn't need the TOC so a lot of corners can be
cut.
>
I am trying to understand the design requirements which are not the same
as the current implementation.
I am pressing this issue because the current definition is unnecessary
restrictive. Even with the restrictions you have given (including
randomization of VDSO base), I am convinced that powerpc32/powerpc64 can
use normal PLT binding for VDSO functions. I also believe this can be
extended to the other platforms. This will be a benefit to all.
It turns out that powerpc32 works as is and powerpc64 should work with
unrelocated (but ReadOnly) .opd's (they will be relocated by
ld64.so/elf_machine_fixup_plt when copied to the PLT). Using the .got or
.toc with the VDSO is slightly more complicated and we can cross that
bridge when we come to it.
For gettimeofday a kludgy interface does not matter (much) but as we look
at other opportunities for processor specific optimizations the overhead
of this interface does matter. A function pointer is slower (~6 cycles)
than a direct branch and the powerpc32 PLT fixup will update the PLT with
a branch absolute (1 cycle), if the targer is anywhere in the lower 32MB
of the address space. On POWER4/5 I can move or compare a lot of bytes in
5 cycles.
> Just look into the efforts to get the vDSO used for gettimeofday as it
> is today. If it wurns out too much work, changes to the vDSO can be
> considered. Otherwise leave it as is.
>
Ok, but as I understand the design requires and trade-offs I will continue
to explore alteratives.
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center