Date: Mon, 2 Apr 2012 11:42:27 -0700 From: Peter Wemm <peter@wemm.org> To: Richard Yao <ryao@cs.stonybrook.edu> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules Message-ID: <CAGE5yCr8955LAF5efT5vQ_%2Bd%2BJdweuANTnPkrGEAYOoANw0kvw@mail.gmail.com> In-Reply-To: <4F766F29.2030803@cs.stonybrook.edu> 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> <4F766F29.2030803@cs.stonybrook.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 30, 2012 at 7:42 PM, Richard Yao <ryao@cs.stonybrook.edu> wrote= : > On 03/30/12 22:15, Peter Wemm wrote: >> On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao <ryao@cs.stonybrook.edu> wr= ote: >>> 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. >>>> 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? >>> >> >> I am the person who wrote it and deliberately chose to cause text >> relocations to be generated on i386. =A0It is by design, not a bug. >> >> All of your concerns are perfectly valid if they were for userland. >> >> For the record, our amd64 modules ALSO do this, but your tools simply >> do not detect it. >> >> Here is what happens, and here is why it is not a problem: >> >> 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. =A0This is so >> that all the relocations can be collected into a single location in >> order to not dirty the MAP_PRIVATE data pages. >> >> 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. =A0The asm instructions would >> look like: >> 0xE8FFEFFFFF =A0(offset is -0x10000) >> >> If the same .so file was loaded in another user process at 0x32345, >> then the relocation would be different. =A0An entire page would be >> dirtied by the dynamic linker so that the second instance of the .so >> file had 0xE8FFDFFFFF (-0x20000). =A0This is a waste of memory and >> causes a storm of VM faults at startup. >> >> Instead, the code is compiled with -fPIC, which causes an extra memory >> reference via the global offset table. =A0Instead of the relocations >> being spread over the text segment, the relocations are in a single >> page. =A0The dynamic linker has to dirty one page only in order to set >> up a whole host of relocations. >> >> The cost is i386 doesn't have native pc-relative mode, so it has to >> waste an entire register. =A0We dedicate one of the 6 general purpose >> registers which costs a hefty performance hit. =A0This is why crypto >> code tends to be compiled without -fpic, for example. >> >> For KERNEL modules, all this changes. >> >> 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. =A0The kernel already does >> this.. if you load a module on one machine it'll ALWAYS be at >> different address space compared to another. >> >> 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. =A0There 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. =A0There is no global offset table. >> >> Both i386 and amd64 use raw relocations, regardless of where the came >> from. =A0Text, data, anywhere. >> >> 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: >> =A0* QA Notice: The following files contain runtime text relocations >> =A0* =A0Text relocations force the dynamic linker to perform extra >> =A0* =A0work at startup, waste system resources, and may pose a security >> =A0* =A0risk. =A0On some architectures, the code may not even function >> =A0* =A0properly, if at all. >> The key here is "dynamic linker". =A0There is no dynamic linker to >> process this stuff. > >> This is simply a tools problem on your end. =A0It'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. No, your tools are checking for, and reporting a USERLAND performance probl= em. A kernel .ko file is NOT used by the USERLAND dynamic linker. Your attempt to invoke ASLR are irrelevant to the situation because ASLR is a USERLAND thing, and kernel modules are ALREADY loaded at random locations. >> There are no security implications, no system resources to be wasted. >> >> 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. "Daaaad! I found a cool security hole but the mean FreeBSD people don't believe me and won't take me seriously! I'm taking my toys and going home, so there! That'll teach them!" I'm not concerned your threat, and I would encourage you to do the research that it would take to implement a proof because you'll learn it doesn't work the way you seem to think it 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. "For all I know". And again, "ASLR".. ASLR is NOT RELEVANT here. Its a kernel file. Not anything to do with the userland dynamic linker where ASLR is implemented. Your argument is akin to saying ".zip files are guaranteed to be a security hole because .zip files might contain a .exe which might have a virus, so therefore .zip files must be banned even the ones containing a .txt file" --=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?CAGE5yCr8955LAF5efT5vQ_%2Bd%2BJdweuANTnPkrGEAYOoANw0kvw>