[uClibc] PATCH: use __libc_gettimeofday instead of gettimeofday

Joakim Tjernlund joakim.tjernlund at lumentis.se
Wed Oct 20 16:30:17 UTC 2004


> On Wed, 20 Oct 2004, Joakim Tjernlund wrote:
> 
> > > On Wed, 20 Oct 2004, Joakim Tjernlund wrote:
> > > 
> > > > > On Wed, 20 Oct 2004, Joakim Tjernlund wrote:
> > > > > 
> > > > > > > > 
> > > > > > > > > If it would be acceptable, I would do the same for
> > > > > > > > > strcpy,strncat,strlen,strncpy,sigaction,kill,sigprocmask
> > > > > > > > > (see last proposed patch in the bug report)
> > > > > > > > 
> > > > > > > > Does the propolice patch really modify all of these libc
> > > > > > > > internals?
> > > > > > > 
> > > > > > > The propolice patch does not modify them, it happens only if the user 
> > > > > > > redefines them (see bug report)
> > > > > > > 
> > > > > > > Peter
> > > > > > 
> > > > > > I think you also need to "hide" these internal functions, otherwise a
> > > > > > user could just as well redefine the internal functions.
> > > > > 
> > > > > an #ifdef _LIBC would be sufficient?
> > > > 
> > > > No, uClibc does not support attribute_hidden, INTUSE, INDDEF etc. as glibc
> > > > does(see include libc_symbols.h in glibc).
> > > > 
> > > > That said, I am not sure iff these symbols really are hidden in glibc. That
> > > > needs to be verified first. However, if you really want to make it impossible
> > > > for a user to redefine a non static symbol, you must "hide" the symbol somehow.
> > > 
> > > Well, what would you do to solve the bug for uClibc? I have tested it by 
> > > replacing read w/ __libc_read and that works.
> > 
> > Define "works". What happens if you try to use the internal name in your test program?
> > Does glibc allow you to use the intenal names in user programs? If yes then I
> > think it is OK for now. If not, you have to look at how glibc does and that
> > involves the attribute_hidden, INTUSE, INTDEF etc. stuff mentioned above.
> 
> I do not use the internal name in the test program. Haven't tested if 
> glibc allows that either.
> 
> The bug report has the test program and describes what happens, if I 
> leave the ssp.c in uClibc as it is, using read, it doubles the reads, if I 
> replace read w/ __libc_read, it does only one read.

Yes, I saw the test program. I am not sure what you want to do here.
Obviously you don't want a user to redefine read(), gettimeofday() etc. for
spp by mistake. But do you care if a user tries to do it on purpose to
trick spp to do something bad? If so, I think you must "hide" the internal functions
from the user.

 Jocke 



More information about the uClibc mailing list