Text relocations in kernel modules

Peter Wemm peter at wemm.org
Wed Apr 4 16:25:49 UTC 2012

On Wed, Apr 4, 2012 at 8:58 AM, Ian Lepore
<freebsd at damnhippie.dyndns.org> wrote:
> This whole relocation question is just a big red herring.  The kernel
> loader relocating a kernel module at load time does not open any
> opportunity for userland code to launch an attack on the memory pages
> into which the module gets loaded.

It is even more of a red herring because the basic assumption of why
the relocation is a problem is invalid.

In userland, a text relocation happens like this:
mprotect(addr, PROT_READ|PROT_EXEC)

It's easy to see why this is something that you'd want to avoid. It
causes a write fault, dirties an entire page, and leaves userland text
writeable for a moment.  Reducing these is worthwhile as a goal of
hardening.  The PaX hardening patches explicitly disable this
mark/unmark phase in userland ld.so.

In userland, a -fPIC cross-file relocation happens like this:

Note that the PLT is always read/write.  If you look at certain tools
that manage code injection you'll see that they intercept the PLT and
can get away with it quite nicely.  Having -fPIC relocations makes it
a little easier because there's a single address to intercept.

In the kernel, there is no distinction between text and data at all.
It is read/write always, there is no write bit flipping, ever.

A kernel text relocation on i386 looks like this:

A kernel text relocation with -fPIC on i386 looks like this:
panic("reloc type not implemented")

A kernel text relocation on amd64 looks like this:

Neither i386 or amd64 do -fPIC modules.  There is no brief window that
text is writeable, because it is always writeable by the kernel, as it
comes from the kernel malloc pool().

Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell

More information about the freebsd-stable mailing list