Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ld.elf_so sources [was Re: HEADS-UP: temporary security problem in today's NetBSD-current]

In article <>,
Nick Hudson  <> wrote:
>On Tuesday 16 November 2010 00:39:58 Christos Zoulas wrote:
>> In article <>,
>> Nick Hudson  <> wrote:
>> >On Sunday 14 November 2010 22:40:11 Matthias Scheler wrote:
>> >> On Sun, Nov 14, 2010 at 11:35:41PM +0100, Marc Balmer wrote:
>> >> > > I'm sorry for the problem but I wasn't expecting that internal
>> >> > > "libc" functions get used outside of "libc".
>> >> >
>> >> > now you owe us beers... ;)
>> >>
>> >> No, the person(s) who committed code that uses internal "libc" function
>> >> all over the source tree deserve a beating^H^H^H^H^H^H^H lecture in
>> >> good software development practices.
>> >
>> >ld.elf_so has done this since it was committed back in 1996 and there are
>> > also lots of examples of "cross over" source file usage.
>> This is not entirely correct in the unsetenv() case. This was recently
>> added to fix a locking issue.
>I realise this now.
>I thought the comment was aimed more at the use of libc_pic.a and/or
>       .PATH.c: ${NETBSDSRCDIR}/lib/libc/misc
>       .PATH.c: ${NETBSDSRCDIR}/lib/libc/stdlib
>> >That said...
>> >
>> >Should someone(tm) move the stuff to src/common so that people don't keep
>> >falling over this?
>> >
>> >Alternatively, I was thinking maybe src/libexec/ld.elf_so/libsmallc (name
>> >suggestions, please) so that it had tight control on what is used from
>> >src/libc. In this way ld.elf_so would fail to build if a src/libc change
>> >dragged in more than it should
>> Well, we need something like that (small functions that don't depend on
>> locking or memory allocation or i18n or....) but the requirements are not
>> entirely clear to me just yet to justify a libsmallc.
> should be small for performance reasons and not drag the everything plus 
>the kitchen sink in from libc_pic.a.
>Additionally, hppa has special requirements around size due to linker 
>deficiencies that mean actually breaks if it bloats too much. This has 
>happened several times due to changes in src/libc
>One day I might find enough energy to fix this linker problem, but that leaves 
>the first point.
>Solutions on a postcard, please.

Well, at least *env() we can easily follow suit with stdio and add:
{unse,pu,{g,s}e}tenv_unlocked() (we only need get and unset for now I think)
to libc and use them in and libpthread, rather than creating
xunsetenv(), and pthread__getenv()... That should be fairly straight-forward.


Home | Main Index | Thread Index | Old Index