Date: Wed, 4 Apr 2012 09:25:47 -0700 From: Peter Wemm <peter@wemm.org> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: freebsd-stable@freebsd.org, jb <jb.1234abcd@gmail.com> Subject: Re: Text relocations in kernel modules Message-ID: <CAGE5yCqCoicok3MaKjwK0ubv%2Bitd4K2AyVr%2BZ0SF%2BKsWCL7pow@mail.gmail.com> In-Reply-To: <1333555093.1090.81.camel@revolution.hippie.lan> References: <CAGE5yCpuvsVrc-%2BDTVas-W4fjuP2s%2B6PQONMOTyEbGnj2CY3ig@mail.gmail.com> <4F766F29.2030803@cs.stonybrook.edu> <CAFHbX1KiZx68MP4bCAvPc0Zui3fA4O35_z3kP781zoJqLYp7Bw@mail.gmail.com> <4F79D88B.3040102@cs.stonybrook.edu> <CAFHbX1KE15G9gx7Duw2R8zC5jL1jiEir0yMB0-s5%2B4xx517WtQ@mail.gmail.com> <4F79E27E.3000509@cs.stonybrook.edu> <CAGE5yCrwLosuTT2yq0DEx%2Bz8ztKpkrB=tORmURcuh_SCz=L7qg@mail.gmail.com> <4F79FCB8.1090003@cs.stonybrook.edu> <CAGE5yCrz45AWeJGv=2UWRq7xpXZVtvsx%2B5O6cvaE6ZzoFrz5mA@mail.gmail.com> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <loom.20120404T103230-175@post.gmane.org> <1333550029.1090.67.camel@revolution.hippie.lan> <loom.20120404T165909-66@post.gmane.org> <1333555093.1090.81.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 4, 2012 at 8:58 AM, Ian Lepore
<freebsd@damnhippie.dyndns.org> wrote:
[..]
> This whole relocation question is just a big red herring. =A0The 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().
--=20
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGE5yCqCoicok3MaKjwK0ubv%2Bitd4K2AyVr%2BZ0SF%2BKsWCL7pow>