Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 Mar 2012 01:46:31 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Richard Yao <ryao@cs.stonybrook.edu>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Text relocations in kernel modules
Message-ID:  <20120330224631.GJ2358@deviant.kiev.zoral.com.ua>
In-Reply-To: <4F76350F.8000708@cs.stonybrook.edu>
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> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

--//MD+r6UUJvz0X/C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 30, 2012 at 06:34:55PM -0400, Richard Yao wrote:
> On 03/30/12 16:36, Konstantin Belousov wrote:
> > 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.
>=20
> readelf is a part of binutils. It is not a script. Here is the version
> that Gentoo/FreeBSD uses:
So you completely missed what I told you.

>=20
> # readelf --version
> GNU readelf (GNU Binutils) 2.20.1.20100303
> Copyright 2009 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) any later
> version.
> This program has absolutely no warranty.
>=20
> In addition, this is what it says when I ask it to look at virtio_blk.ko:
>=20
> # readelf -d /boot/modules/virtio_blk.ko
>=20
> Dynamic section at offset 0x2f6c contains 13 entries:
>   Tag        Type                         Name/Value
>  0x00000004 (HASH)                       0xd4
>  0x6ffffef5 (GNU_HASH)                   0x480
>  0x00000005 (STRTAB)                     0x9d0
>  0x00000006 (SYMTAB)                     0x4e0
>  0x0000000a (STRSZ)                      1295 (bytes)
>  0x0000000b (SYMENT)                     16 (bytes)
>  0x00000011 (REL)                        0xee0
>  0x00000012 (RELSZ)                      1664 (bytes)
>  0x00000013 (RELENT)                     8 (bytes)
>  0x00000016 (TEXTREL)                    0x0
>  0x0000001e (FLAGS)                      TEXTREL
>  0x6ffffffa (RELCOUNT)                   87
>  0x00000000 (NULL)                       0x0
>=20
> Running the same command on amd64 FreeBSD's version returns nothing. I
> have attached the result of `readelf -a ...` on both the i386 version
> and the amd64 version.
Reread what I wrote to you. Also, it pays off learning how ELF works
before making conclusion from the absence of the output of readelf -d.
Amd64 modules _are not_ shared objects.

>=20
> > 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.
>=20
> I believe that relocations also cause the linker to work harder when the
> modules themselves are loaded the first time. They can also cause bugs
> when code is ported to another architecture.
I can only answer that this is your fantasy, however ample.
I see that conversation is going nowhere, I will not reply further.

>=20
> > On the other hand, there is only one instance of the loaded kernel modu=
le,
> > 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.
>=20
> Compiling with -fPIC breaks the build.
>=20
> > 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.
>=20
> Linux has no such text relocations in its modules. I have checked on
> both i386 and amd64. I have difficulty believing that FreeBSD needs text
> relocations when Linux does not.
>=20
> I am fairly certain that this is going to interfere with ASLR in the
> kernel, which is a security issue. It is definitely something to report.

--//MD+r6UUJvz0X/C
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAk92N8cACgkQC3+MBN1Mb4i32wCeILV0GitT3U/Z5bgGfdyecQ8K
MdcAoM9n3gz5fZBqoupD0SJdSGDOEvcf
=CXW4
-----END PGP SIGNATURE-----

--//MD+r6UUJvz0X/C--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120330224631.GJ2358>