Text relocations in kernel modules

[Ian Lepore]

On Wed, 2012-04-04 at 08:38 +0000, jb wrote:
> <kpneal <at> pobox.com> writes:
> 
> > ... 
> > You can appeal to authority by saying the Gentoo Hardened developers said
> > such-and-such all you want, but it would be more useful for you to be able
> > to make specific technical arguments yourself. Saying "it could be a
> > problem" or "in the wild there may be" isn't useful. A valid technical
> > argument giving a mechanism for relocations to be exploited is all that
> > is needed for you to prove your point.
> > ...
> 
> I have a question regarding security of FreeBSD kernel module loading and
> relocation.
> 
> According to KLDLOAD(8): 
> "...The kldload utility loads file.ko into the kernel using the kernel
>      linker. ..."
> 
> So, kernel module is loaded:
> # kldload /boot/kernel/foo.ko
> 
> Here is my question: is foo.ko modified at this time ? Due to relocations ?
> 
> The reason I ask about it is this Gentoo Hardened FAQ item:
> 
> http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#paxnoelf
> 
> "I keep getting the message: "error while loading shared libraries: cannot make
> segment writable for relocation: Permission denied." What does this mean?"
> 
> I understand this is about .so and does not apply directly to .ko .
> 
> But of interest to me is this:
> "...
> Text relocations are a way in which references in the executable code to
> addresses not known at link time are solved. Basically they just write
> the appropriate address at runtime marking the code segment writable in order
> to change the address then unmarking it. This can be a problem as an attacker
> could try to exploit a bug when the text relocation happens in order to be able
> to write arbitrary code in the text segment which would be executed.
> ..."
> 
> Now, let me apply the above quoted paragraph to .ko and ask my question again,
> this time being more specific:
> 
> are you doing any "marking" and "unmarking" of it at relocations and load time,
> thus creating an attack window opportunity ?
> 
> jb

Even though you acknowledge it, your question seems to contradict an
understanding of the concept that a .ko is not a shared library.  The
"marking and unmarking" you refer to would apply to pages that are
shared among multiple processes and have to be relocated repeatedly into
each process's address space.  A kernel module is loaded and linked
ONCE, at load time, into the kernel's address space.  It is not shared
and never needs to be relocated again into another address space.

In other words, the paragraph you cite doesn't have any meaning in the
context of a .ko, because a .ko isn't a userland shared library.

It's also interesting to me to note that even in a userland shared
library, whether there are text relocations scattered throughout the
text segment or they're all gathered into one table the way PIC code
works, the same number of relocations have to happen to link the library
into a new address space.  The only difference is whether many pages get
touched because the relocations are scattered, or only a few pages
because they're all clumped together.  The PIC scheme is designed to
maximize code sharing by eliminating the need to copy-on-write many
modified pages.  I wonder how it became associated with increased
security?  I don't see the increase.

-- Ian