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

[christos%astron.com@localhost (Christos Zoulas)]

In article <201011161816.37113.nick.hudson%gmx.co.uk@localhost>,
Nick Hudson  <nick.hudson%gmx.co.uk@localhost> wrote:
>On Tuesday 16 November 2010 00:39:58 Christos Zoulas wrote:
>> In article <201011150733.49603.nick.hudson%gmx.co.uk@localhost>,
>> 
>> Nick Hudson  <nick.hudson%gmx.co.uk@localhost> 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.
>
>ld.so 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 ld.so 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 ld_elf.so and libpthread, rather than creating
xunsetenv(), and pthread__getenv()... That should be fairly straight-forward.

christos