From owner-freebsd-arch@FreeBSD.ORG Wed Mar 21 20:59:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F427106564A for ; Wed, 21 Mar 2012 20:59:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0D81D8FC0C for ; Wed, 21 Mar 2012 20:59:10 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 43FFB46B1A; Wed, 21 Mar 2012 16:59:03 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CA18DB940; Wed, 21 Mar 2012 16:59:02 -0400 (EDT) From: John Baldwin To: Doug Ambrisko Date: Wed, 21 Mar 2012 16:55:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201203211711.q2LHBbO2026327@ambrisko.com> In-Reply-To: <201203211711.q2LHBbO2026327@ambrisko.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203211655.46443.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 21 Mar 2012 16:59:02 -0400 (EDT) Cc: freebsd-arch@freebsd.org Subject: Re: rtld enhancement to add osversion, version 2 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:59:10 -0000 On Wednesday, March 21, 2012 1:11:37 pm Doug Ambrisko wrote: > | > This doesn't solve the LD_LIBRARY_PATH or LD_PRELOAD. Solving that > | > I still insert and iterate over the osverion, major and none into the > | > path to find the library. The reason for this is that a FreeBSD 8 > | > binary could exec a FreeBSD 6 binary that execs a FreeBSD 7 binary. > | > If for the FreeBSD 6 binary we needed to set a custom LD_LIBRARY_PATH > | > and the FreeBSD 7 binary find a library via the FreeBSD 6 search path > | > then the FreeBSD 7 binary would die. By adding in the osversion search > | > path I can put the FreeBSD 6 library into the search path + the directory > | > 6. Then only FreeBSD 6 binaries can find it. An example: > | > LD_LIBRARY_PATH=/usr/custom_software/lib > | > /usr/custom_software/lib/6/libfoo.so.6 > | > then only the FreeBSD 6 binary could load it. Since the searches > | > would be for the FreeBSD 6 binary: > | > /usr/custom_software/lib/603000/libfoo.so.6 > | > /usr/custom_software/lib/6/libfoo.so.6 > | > /usr/custom_software/lib/libfoo.so.6 > | > and for FreeBSD 7 binary: > | > /usr/custom_software/lib/702000/libfoo.so.6 > | > /usr/custom_software/lib/7/libfoo.so.6 > | > /usr/custom_software/lib/libfoo.so.6 > | > Only the FreeBSD 6 binary would load /usr/custom_software/lib/6/libfoo.so.6. > | > I do the same search with LD_PRELOAD. > | > | Hmm, I'm still not quite fan of this. Perhaps you could add an extension to > | ldconfig and the hints file to handle this case? That is, a way to store > | path mappings so you could do something like: > | > | ldconfig -os=6 -p /usr/local/lib /usr/local/lib/6 > > I'll have to look to see how the hints file could update rtld. It is > an interesting idea. Maybe libmap.conf would be better place for this. > I haven't looked at how libmap works. Maybe introduce: > /etc/libmap-.conf > that maps paths as well. So with the above example. > /etc/libmap-6.conf > would contain > /usr/custom_software/lib /usr/custom_software/lib/6:/usr/custom_software/lib > for example. > > | Or maybe you could make it an extension of how 'm' worked, so you could make > | directories accept an optional set of colon-separated paths that they serve > | as aliases for: > | > | ldconfig -os=6 -m /usr/local/lib/6:/usr/local/lib:/usr/lib > > I don't really get how this is solving the LD_LIBRARY_PATH/LD_PRELOAD since > "-m" is solving the general case with the hints file which I did first. It is just an alternate suggestion to the -p thing above. Having a libmap.conf option to establish the mappings would be fine with me as well. I would just like to have the library paths be something the user explicitly configures rather than having rtld perform black-box path manipulations itself. > | > Final, is that prior binaries built on FreeBSD i386 but run on FreeBSD amd64 > | > that set LD_* environemnt variables would fail on FreeBSD amd64 as is > | > since it didn't set the equivalent LD32_*. To address this for COMPAT_32BIT > | > I have rtld look for LD32_* first and then check for the LD_* second. > | > This way legacy applications work fine. > | > | Hmm, so Yahoo! had some patches to handle this as well. I think Yahoo's > | patches were different though. They actually patched the 32-bit libc to > | capture attempts to get or set LD_* and convert them to actually get/set > | LD32_* instead. I'm not sure which approach is best, but it might be worth > | asking Peter why Yahoo! did it that way and if there were reasons for that > | approach vs. doing it in rtld. I think the primary reason was so that you > | could set LD_LIBRARY_PATH or LD_PRELOAD to reference 64-bit libraries and > | not have it break 32-bit apps, but if a 32-bit app tried to set a variable > | before launching another app it would still DTRT. > > This means you would have to have a modified libc in these environment > and it wouldn't help in the static binary case. I think we are safe > in the case LD_ for a 32 bit binary effecting a 64 bit since rtld should > not allow loading a the wrong type of lib. into a binary. I can do some > more testing around that area. I was trying to keep all changes in the > host environment so we can run unchanged binaries from other vendors. Yes, I'm not quite convinced which approach is best, mostly I just wanted to point out the alternative approach so both could be considered. -- John Baldwin