Text relocations in kernel modules
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_WRITE|PROT_EXEC, PAGE_SIZE);
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