Text relocations in kernel modules

[Konstantin Belousov]

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.
> 
> 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.

> 
> # 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.
> 
> In addition, this is what it says when I ask it to look at virtio_blk.ko:
> 
> # readelf -d /boot/modules/virtio_blk.ko
> 
> 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
> 
> 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.

> 
> > 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.
> 
> 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.

> 
> > 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.
> 
> Compiling with -fPIC breaks the build.
> 
> > 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.
> 
> 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.
> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120330/d13ec1c2/attachment.pgp