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

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

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.

Nick