From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 20:36:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD3791065705 for ; Fri, 30 Mar 2012 20:36:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 339568FC0C for ; Fri, 30 Mar 2012 20:36:22 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q2UKa60t057609; Fri, 30 Mar 2012 23:36:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q2UKa55K026699; Fri, 30 Mar 2012 23:36:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q2UKa5Zu026698; Fri, 30 Mar 2012 23:36:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Mar 2012 23:36:05 +0300 From: Konstantin Belousov To: Richard Yao Message-ID: <20120330203605.GI2358@deviant.kiev.zoral.com.ua> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0xbckOs9ckBzXei" Content-Disposition: inline In-Reply-To: <4F761371.7020606@cs.stonybrook.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 20:36:23 -0000 --i0xbckOs9ckBzXei Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2012 at 04:11:29PM -0400, Richard Yao wrote: > On 03/30/12 15:46, Konstantin Belousov wrote: > > On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote: > >> On 03/30/12 15:07, Konstantin Belousov wrote: > >>>> Is this a bug? > >>> No. This is by design. > >>> > >>> Why do you consider this a bug ? > >> > >> It occurs on i386, but not amd64. It could be that something is wrong > >> with how things are being compiled i386, or it could be that i386 > >> requires things to be compiled this way. I do not know which. > >> > > Again, let me repeat my question. Why do you consider the presence > > of relocations against text section a problem ? >=20 > The linker emits warnings: > i686-gentoo-freebsd9.0-ld: warning: creating a DT_TEXTREL in object. >=20 > Furthermore, this triggers a QA check in Gentoo/FreeBSD's package manager. >=20 > * QA Notice: The following files contain runtime text relocations > * Text relocations force the dynamic linker to perform extra > * work at startup, waste system resources, and may pose a security > * risk. On some architectures, the code may not even function > * properly, if at all. > * For more information, see http://hardened.gentoo.org/pic-fix-guide.xml > * Please include the following list of files in your report: > * TEXTREL boot/modules/if_vtnet.ko > * TEXTREL boot/modules/virtio_blk.ko > * TEXTREL boot/modules/virtio.ko > * TEXTREL boot/modules/virtio_balloon.ko > * TEXTREL boot/modules/virtio_pci.ko >=20 > I wrote that ebuild as part of something entirely unrelated. If it is a > feature, I can disable the QA check, but I should at least know why the > text relocations are needed. >=20 > Gentoo maintainers are expected to patch text relocations and send > patches upstream. The only exception is in the case of binary packages, > which they cannot patch. >=20 > Investigating the text relocations in my port of emulators/virtio-kmod > revealed that all kernel modules on i386 Gentoo/FreeBSD have text > relocations, yet none have them on amd64 FreeBSD, so I do not know > whether this is a bug or a feature. >=20 First, there _are_ relocations against text in the amd64 modules, but I suspect that your scripts do not detect this. Most likely, scripts look for DT_TEXTREL dynamic tag, and tags are only present in the executables or shared objects, not in the object files. The amd64 modules are object files, so you just mis-interpret the situation. Second, from what you wrote, I see the issue in either wrong policy being established in your project, or (another) mis-interpretation of the policy. Indeed, having text relocations in the shared objects is bad, because said relocations hinder text pages sharing. Relocated page is modified, so COW mechanism causes it to become private to process. On the other hand, there is only one instance of the loaded kernel module, its text segment (or section, for amd64) is not shared, so modifications to the text pages do not cause increased memory use. More, not compiling modules with -fPIC (absence of -fPIC is what makes the text relocations to appear in the final link result) makes the code faster, esp. on i386. So, there is nothing to report, and fix is outside the FreeBSD domain: either fix your policy by not stating that text relocation in kernel module is banned, or just find that policy only applicable to usermode objects. --i0xbckOs9ckBzXei Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk92GTQACgkQC3+MBN1Mb4g7cQCgnitw46a68Tb8cyxG+6Ze2KOZ MkAAoNetmv8hRzJLz7mBs0pRq8Fqdx+4 =e9HE -----END PGP SIGNATURE----- --i0xbckOs9ckBzXei--