Date: Fri, 30 Mar 2012 22:42:49 -0400 From: Richard Yao <ryao@cs.stonybrook.edu> To: Peter Wemm <peter@wemm.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules Message-ID: <4F766F29.2030803@cs.stonybrook.edu> In-Reply-To: <CAGE5yCpuvsVrc-%2BDTVas-W4fjuP2s%2B6PQONMOTyEbGnj2CY3ig@mail.gmail.com> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <CAGE5yCpuvsVrc-%2BDTVas-W4fjuP2s%2B6PQONMOTyEbGnj2CY3ig@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--------------enigEABF9CB5010413DE1E789077 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/30/12 22:15, Peter Wemm wrote: > On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao <ryao@cs.stonybrook.edu> w= rote: >> On 03/30/12 18:46, Konstantin Belousov wrote: >>> Reread what I wrote to you. Also, it pays off learning how ELF works >>> before making conclusion from the absence of the output of readelf -d= =2E >>> Amd64 modules _are not_ shared objects. >> >> Whether or not they are shared objects is irrelevant. The fact is that= >> they have text relocations, which interfere with ASLR. Do I need to >> produce exploit code before you take me seriously? >> >=20 > I am the person who wrote it and deliberately chose to cause text > relocations to be generated on i386. It is by design, not a bug. >=20 > All of your concerns are perfectly valid if they were for userland. >=20 > For the record, our amd64 modules ALSO do this, but your tools simply > do not detect it. >=20 > Here is what happens, and here is why it is not a problem: >=20 > When you compile with -fpic on an architecture that doesn't support > PC-relative addressing adequately, the compiler generates code to do > indirect memory references via the global offset table. This is so > that all the relocations can be collected into a single location in > order to not dirty the MAP_PRIVATE data pages. >=20 > example: > if there is an function at 0x12345, and another function in a > different .so file that wants to call it at 0x22345, then the call > instruction would have to be relocated. The asm instructions would > look like: > 0xE8FFEFFFFF (offset is -0x10000) >=20 > If the same .so file was loaded in another user process at 0x32345, > then the relocation would be different. An entire page would be > dirtied by the dynamic linker so that the second instance of the .so > file had 0xE8FFDFFFFF (-0x20000). This is a waste of memory and > causes a storm of VM faults at startup. >=20 > Instead, the code is compiled with -fPIC, which causes an extra memory > reference via the global offset table. Instead of the relocations > being spread over the text segment, the relocations are in a single > page. The dynamic linker has to dirty one page only in order to set > up a whole host of relocations. >=20 > The cost is i386 doesn't have native pc-relative mode, so it has to > waste an entire register. We dedicate one of the 6 general purpose > registers which costs a hefty performance hit. This is why crypto > code tends to be compiled without -fpic, for example. >=20 > For KERNEL modules, all this changes. >=20 > In userland, there is a dynamic linker. In the kernel, there is none. > In userland, the .so files are mapped with mmap(MAP_PRIVATE), the > kernel does not use mmap and always uses a private copy. > In userland, the .so files are shared, the kernel NEVER shares them. > In userland, doing a relocation causes a copy on write fault, this > never happens to the kernel because its using private, exclusive > malloc() pages. > In userland, we make the performance tradeoff from -fpic in order to > share memory pages, the kernel never shares pages so -fpic is a waste. > In userland, ASLR has security benefits. The kernel already does > this.. if you load a module on one machine it'll ALWAYS be at > different address space compared to another. >=20 > In FreeBSD/i386, we use 'ld -shared -o foo.ko *.o', to wrap the non > pic .o files into a container that was more convenient at the time to > parse. There is no global-offset-table. > In FreeBSD/amd64, we use 'ld -r -o foo.ko *.o' to wrap the same > non-pic code into a less convenient form that we can feed back into > the linker if we wish. There is no global offset table. >=20 > Both i386 and amd64 use raw relocations, regardless of where the came > from. Text, data, anywhere. >=20 > This has nothing to do with ASLR, because they are kernel objects, not > shared libraries. Most people seem to think that I am unaware of these things, but I already knew most of it. Note that this mostly applies to remarks people are sending me privately. With that said, thank you for the detailed explanation. It filled in a few blanks that I had, specifically in how FreeBSD does things. > You posted: > * QA Notice: The following files contain runtime text relocations > * Text relocations force the dynamic linker to perform extra > * work at startup, waste system resources, and may pose a security > * risk. On some architectures, the code may not even function > * properly, if at all. > The key here is "dynamic linker". There is no dynamic linker to > process this stuff. > This is simply a tools problem on your end. It's not a bug. My tools are doing what they were supposed to do. However, people on the list seem to think that the idea that they are checking for a problem to be a matter of opinion. > There are no security implications, no system resources to be wasted. >=20 > And if you think there are security implications, then lets see a > proof-of-concept. If I find time to write a proof-of-concept, I promise to publish it publicly. Your security team will find out when everyone else does. You can argue otherwise, but for all I know, exploit code that ASLR breaks is already in the wild. I believe that nothing short of full disclosure would be beneficial to your users' security. > I have given you a detailed explanation of why it's not a problem. If > you want to continue, then reply with details, not hearsay or > theories. I asked why things were one way and certain people were rather rude. There is no need to join them in that. Anyway, my question is answered. Thanks. --------------enigEABF9CB5010413DE1E789077 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPdm8vAAoJELFAT5FmjZuEdBEQAM2+/ab+BamQhtWwcOMx/GMY /oqxCec4dwxUIMCqQGcATEsqUeHtJK0kjcJ+xsY8nc3UGsfzGQum4bqYxRY4JWHv iL7vXHYMpxmynys2jFtpcjS7Fx/wru5X1aMPbOzbZLmYy6UUHpPYXNKA+mVgLYYH j0cCRhKyhfSy/n5gx7wvRwDULEW5HLetsdrw3wgDj0VfDXwwEVZ3G22fiL+w8UsU i1QDxA9kB0agxQRuMO/kAEFDE2A9xP0b26G1ZtXz2dMNlq6T2701pVeXPJDw1Lf6 P6ifpgQuxnaxZPDtT3OXpTpPGIS5WyMppnfE6po7iHNNm9dMXYBH5CoJXjz5ewVo 4g1xoibeLQ6AQr7xf+d6JUh21s1Zv6aHaQB8Q32DNGmklOuSUs84xcP/dpoudjfB NxNfjC27L+tnD9y9rKI9d9NRshsPLRBhAI49yurB/nWvGEjkqGJDAGjJrn2blNdf 8igqV4OEYxRHc3AHbcdkcdq1lQ/lh+oko0mbrg1SIpNZ+hzyeZoohxpEcgWEDNko YW7Iwa9dZRLmsffvAhRAusleePwcViOHeUoAxlF/W4ahKwne5ckWJyroloKjB0tH 2EGBBJzkQcYlvHNawUTFTf20obOXXdr2dw22VIcfqdWuTCFwOYXFadEk20WyIrUx ETc+D3g3loc6G1jAkkVx =jykJ -----END PGP SIGNATURE----- --------------enigEABF9CB5010413DE1E789077--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F766F29.2030803>