Date: Thu, 23 Apr 1998 13:45:19 +1000 (EST) From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking Message-ID: <199804230345.NAA20055@gsms01.alcatel.com.au>
next in thread | raw e-mail | index | archive | help
On Wed, 22 Apr 1998 18:01:46 -0500 (EST), "John S. Dyson" <dyson@FreeBSD.ORG> wrote:
>I haven't been watching this discussion carefully, but here
>are the costs of shared libs:
>
> fork() performance is slower.
This is virtually solely due to the cost of duplicating the larger
page tables. In reality (and given the COW semantics, which delay
the actual page table duplication), how much slower is forking a
dynamic executable together with its shared libraries than forking
a static executable (where much of the library code is embedded in
the executable anyway)?
> exec() performance is effectively slower (due to ld.so.)
This is a big killer. Unfortunately, I don't have any magic
solutions.
> Shared libs often require additional page table pages
> to map them.
I'm not familiar with the low-level VM, so the answer to this might
be obvious: Why can't the page tables associated with shared libraries
be shared between processes? I know they won't get inherited, but
can't mmap() share page tables as well as the underlying objects?
>Here are the non-advantages:
>
> Shared libs don't help .text sharing,
I don't quite follow this one. Isn't being able to share a single
copy of libc.so across (almost) every process on the system better
than sharing the part of libc.a compiled into /bin/sh across several
dozen sh processes, with a second copy of much the same code being
shared across several dozen csh processes (for example)?
>My suggestions for programs that should probably not be linked shared
>under any circumstances:
> If the shared
> libs are on /usr, any program that needs to be
> able to work without /usr mounted.
This translates as `if the shared libraries are in /usr, / should
only contain statically linked programs'. If we had a (subset) of
the shared libraries on /, this point is irrelevent.
>Programs where it is likely slightly advantageous to link shared:
> cc1, cc1plus,
Actually, for programs where the text+data is very large compared to
the libraries (the above, plus emacs and maybe perl(*)) the space
savings incurred using shared libraries are probably outweighed by the
performance gains through making them static.
Also, I think John has ignored some of the advantages of shared
libraries:
- Fixing bugs in libraries is much easier - just replace a single
libc.so and the bug is fixed in all the programs that use it. This
mightn't be much of an issue for the hackers amongst us (who
regularly rebuild their entire systems), but will be an issue
as we try to expand our user base to less knowledgable people
(and people who don't want to have to do a `make world' every
time a CERT advisory comes out).
- Run-time control (and extendability) of configuration. Examples
are Sun's name service switch and volume management, as well as
the idea of plug-in authentication modules for login (where this
thread started).
(*) In reality, perl5 needs access to the dynamic loader anyway and
so isn't as good a choice.
Peter
--
Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au
Alcatel Australia Limited
41 Mandible St Phone: +61 2 9690 5019
ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804230345.NAA20055>