On Wed, Apr 4, 2012 at 8:58 AM, Ian Lepore
<free...@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);
fixup_text_relocation()
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:
fixup_readwrite_PLT_relocation()
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:
fixup_relocation();
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:
fixup_relocation().
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 - pe...@wemm.org; pe...@freebsd.org; pe...@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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
