This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]