[uClibc] PATCH: use __libc_gettimeofday instead of gettimeofday

Peter S. Mazinger ps.m at gmx.net
Wed Oct 20 20:50:47 UTC 2004


On Wed, 20 Oct 2004, Joakim Tjernlund wrote:

> > On Wed, 20 Oct 2004, Peter S. Mazinger wrote:
> > 
> > > On Wed, 20 Oct 2004, Joakim Tjernlund wrote:
> > > 
> > > > > 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.
> > > 
> > > What I want is to get rid of the double execution.
> > > I do not know why it happens if ssp.c is compiled into uclibc (it happens 
> > > w/ glibc too), there are other source files that use these functions too 
> > > and those do not produce such a result (or noone found it until know)
> > > So to get rid of them at least in ssp.c, all have to be replaced w/ 
> > > internal versions, but not all are present currently in uClibc, so these 
> > > have to be provided. The first step was to provide __libc_gettimeofday and 
> > > use it, if it is accepted, I'll try to do the others too, else if not 
> > > accepted I'll stay w/ an ssp.c where only parts of the functions are 
> > > replaced w/ internal ones.
> > > ones.
> > 
> > I have tested it the other way round too, ssp.c "is corrected" using
> > __libc_read, and I changed read to __libc_read in the test program. It 
> > does the same, it reads twice (the same applies to glibc too w/ __read)
> > Both libc's allow the use of the internal versions, so what remains to 
> > be answered, why does it happen because of ssp.c and not some other parts 
> > in uClibc, that use the read (and the other) functions.
> 
> What "some other parts"?
for ex. the files below use read()
tempname.c,rcmd.c,rexec.c,svc_tcp.c,time.c,wordexp.c
how does it come, that these don't produce the double read result?

> What happens if ssp.c is part of(compiled into) glibc? Do you require ssp.c to always use the internal
> functions in libc even if the user has redefined the internal functions?

The same ssp.c (attached earlier) was compiled into glibc too, the patch 
mentioned in bug should solve for both the "problem".
How should we know what the user really does, currently for uClibc if I 
use __libc_read in ssp.c, then the user may redefine read and viceversa. 
If he uses the same as we in ssp.c, it double reads.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list