From owner-freebsd-security Wed Apr 22 20:46:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA21325 for freebsd-security-outgoing; Wed, 22 Apr 1998 20:46:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.alcatel.com.au (gatekeeper.alcatel.com.au [203.17.66.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA21279 for ; Thu, 23 Apr 1998 03:46:06 GMT (envelope-from peter.jeremy@alcatel.com.au) Received: from mfg1.cim.alcatel.com.au ([139.188.23.1]) by gatekeeper.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IW7LM38JPS000LLF@gatekeeper.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Thu, 23 Apr 1998 13:45:30 +1000 Received: from cbd.alcatel.com.au by cim.alcatel.com.au (PMDF V5.1-10 #U2695) with ESMTP id <01IW7LLSR8CWDDZ5GV@cim.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Thu, 23 Apr 1998 13:45:16 +1000 Received: from gsms01.alcatel.com.au by cbd.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IW7LLX3PAOAZTUBC@cbd.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Thu, 23 Apr 1998 13:45:21 +1100 Received: (from jeremyp@localhost) by gsms01.alcatel.com.au (8.8.8/8.7.3) id NAA20055 for freebsd-security@FreeBSD.ORG; Thu, 23 Apr 1998 13:45:19 +1000 (EST) Date: Thu, 23 Apr 1998 13:45:19 +1000 (EST) From: Peter Jeremy Subject: Re: Static vs. dynamic linking To: freebsd-security@FreeBSD.ORG Message-id: <199804230345.NAA20055@gsms01.alcatel.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 22 Apr 1998 18:01:46 -0500 (EST), "John S. Dyson" 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