As a disclaimer, I would like to clarify that Gentoo/FreeBSD uses a FreeBSD userland and that Gentoo/FreeBSD has nothing to do with Debian GNU/kFreeBSD. People seem to think Gentoo/FreeBSD is related to Debian GNU/kFreeBSD, which has made collaboration difficult. With that said, Gentoo Portage is warning about text relocations in kernel modules. This is in a Gentoo/FreeBSD port of emulators/freebsd-kmod that I wrote. For instance, I see: # readelf -d /boot/modules/virtio.ko Dynamic section at offset 0x2f6c contains 13 entries: Tag Type Name/Value 0x00000004 (HASH) 0xd4 0x6ffffef5 (GNU_HASH) 0x238 0x00000005 (STRTAB) 0x4a8 0x00000006 (SYMTAB) 0x298 0x0000000a (STRSZ) 397 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000011 (REL) 0x638 0x00000012 (RELSZ) 1568 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x00000016 (TEXTREL) 0x0 0x0000001e (FLAGS) TEXTREL 0x6ffffffa (RELCOUNT) 108 0x00000000 (NULL) 0x0 Checking /boot/kernel, it seems that all modules have text relocations. My Gentoo/FreeBSD install is a 32-bit chroot on a ZFS Guru install of amd64 FreeBSD. amd64 FreeBSD does not appear to have any text relocations. I don't have a reference i386 install, but according to frogs in ##freebsd on freenode, his i386 FreeBSD also has text relocations. Is this a bug? Yours truly, Richard Yao On 03/30/12 12:49, Richard Yao wrote:> Dear Ports Maintainers and kuriyama, > > emulators/freebsd-kmod has a typo in pkg-descr, where it says "lodable" > instead of "loadable". > > In addition, I have done the work necessary to port > emulators/freebsd-kmod to Gentoo/FreeBSD. > > https://bugs.gentoo.org/show_bug.cgi?id=410199 > > The ebuild contains a few improvements on the original FreeBSD port > where we copy only the parts of SYSDIR that we need to build the module. > We also do hardlinks instead of copies when Gentoo Portage builds with > user privileges. > > The NEEDSUBDIRS part of the ebuild was written by naota AT gentoo.org as > part of Gentoo's review process. I have permission from him to upstream > the improvements we made on the port. Feel free to adopt any > improvements in the attachments in that bug report. > > Lastly, I have sent an email to gentoo-dev AT lists.gentoo.org and > gentoo-bsd AT lists.gentoo.org requesting that the FreeBSD specific > parts of the portage tree be relicensed under terms of the BSD-2 > license. With a little luck, it will be possible to upstream > improvements made in Gentoo/FreeBSD without any hassle in the future. > > Yours truly, > Richard Yao >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120330/a394592a/signature.pgp
On Fri, Mar 30, 2012 at 01:38:14PM -0400, Richard Yao wrote:> As a disclaimer, I would like to clarify that Gentoo/FreeBSD uses a > FreeBSD userland and that Gentoo/FreeBSD has nothing to do with Debian > GNU/kFreeBSD. People seem to think Gentoo/FreeBSD is related to Debian > GNU/kFreeBSD, which has made collaboration difficult. > > With that said, Gentoo Portage is warning about text relocations in > kernel modules. This is in a Gentoo/FreeBSD port of > emulators/freebsd-kmod that I wrote. For instance, I see: > > # readelf -d /boot/modules/virtio.ko > > Dynamic section at offset 0x2f6c contains 13 entries: > Tag Type Name/Value > 0x00000004 (HASH) 0xd4 > 0x6ffffef5 (GNU_HASH) 0x238 > 0x00000005 (STRTAB) 0x4a8 > 0x00000006 (SYMTAB) 0x298 > 0x0000000a (STRSZ) 397 (bytes) > 0x0000000b (SYMENT) 16 (bytes) > 0x00000011 (REL) 0x638 > 0x00000012 (RELSZ) 1568 (bytes) > 0x00000013 (RELENT) 8 (bytes) > 0x00000016 (TEXTREL) 0x0 > 0x0000001e (FLAGS) TEXTREL > 0x6ffffffa (RELCOUNT) 108 > 0x00000000 (NULL) 0x0 > > Checking /boot/kernel, it seems that all modules have text relocations. > My Gentoo/FreeBSD install is a 32-bit chroot on a ZFS Guru install of > amd64 FreeBSD. amd64 FreeBSD does not appear to have any text relocations. > > I don't have a reference i386 install, but according to frogs in > ##freebsd on freenode, his i386 FreeBSD also has text relocations. > > Is this a bug?No. This is by design. Why do you consider this a bug ?> > Yours truly, > Richard Yao > > On 03/30/12 12:49, Richard Yao wrote: > > Dear Ports Maintainers and kuriyama, > > > > emulators/freebsd-kmod has a typo in pkg-descr, where it says "lodable" > > instead of "loadable". > > > > In addition, I have done the work necessary to port > > emulators/freebsd-kmod to Gentoo/FreeBSD. > > > > https://bugs.gentoo.org/show_bug.cgi?id=410199 > > > > The ebuild contains a few improvements on the original FreeBSD port > > where we copy only the parts of SYSDIR that we need to build the module. > > We also do hardlinks instead of copies when Gentoo Portage builds with > > user privileges. > > > > The NEEDSUBDIRS part of the ebuild was written by naota AT gentoo.org as > > part of Gentoo's review process. I have permission from him to upstream > > the improvements we made on the port. Feel free to adopt any > > improvements in the attachments in that bug report. > > > > Lastly, I have sent an email to gentoo-dev AT lists.gentoo.org and > > gentoo-bsd AT lists.gentoo.org requesting that the FreeBSD specific > > parts of the portage tree be relicensed under terms of the BSD-2 > > license. With a little luck, it will be possible to upstream > > improvements made in Gentoo/FreeBSD without any hassle in the future. > > > > Yours truly, > > Richard Yao > > > >-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120330/e2b972f3/attachment.pgp
On 03/30/12 15:07, Konstantin Belousov wrote:>> Is this a bug? > No. This is by design. > > Why do you consider this a bug ?It occurs on i386, but not amd64. It could be that something is wrong with how things are being compiled i386, or it could be that i386 requires things to be compiled this way. I do not know which. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120330/897dc8f5/signature.pgp
On 03/30/12 15:46, Konstantin Belousov wrote:> On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote: >> On 03/30/12 15:07, Konstantin Belousov wrote: >>>> Is this a bug? >>> No. This is by design. >>> >>> Why do you consider this a bug ? >> >> It occurs on i386, but not amd64. It could be that something is wrong >> with how things are being compiled i386, or it could be that i386 >> requires things to be compiled this way. I do not know which. >> > Again, let me repeat my question. Why do you consider the presence > of relocations against text section a problem ?The linker emits warnings: i686-gentoo-freebsd9.0-ld: warning: creating a DT_TEXTREL in object. Furthermore, this triggers a QA check in Gentoo/FreeBSD's package manager. * 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. * For more information, see http://hardened.gentoo.org/pic-fix-guide.xml * Please include the following list of files in your report: * TEXTREL boot/modules/if_vtnet.ko * TEXTREL boot/modules/virtio_blk.ko * TEXTREL boot/modules/virtio.ko * TEXTREL boot/modules/virtio_balloon.ko * TEXTREL boot/modules/virtio_pci.ko I wrote that ebuild as part of something entirely unrelated. If it is a feature, I can disable the QA check, but I should at least know why the text relocations are needed. Gentoo maintainers are expected to patch text relocations and send patches upstream. The only exception is in the case of binary packages, which they cannot patch. Investigating the text relocations in my port of emulators/virtio-kmod revealed that all kernel modules on i386 Gentoo/FreeBSD have text relocations, yet none have them on amd64 FreeBSD, so I do not know whether this is a bug or a feature. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120330/bd3bc7ef/signature.pgp
On Fri, Mar 30, 2012 at 6:51 PM, <kpneal@pobox.com> wrote:> On Fri, Mar 30, 2012 at 06:47:15PM -0400, Richard Yao wrote: >> 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? > > Any time you have any reference from a single compilation's object module > to any code or data in a different compilation you need some way for one > object to find that code/data. > > Think about it: if a function call is going to branch to another function > it needs to know the address of the target function. How can it get this > target address? Relocations. > > Now, move up a bit to kernel objects which typically consist of multiple > compilations all linked together. If a function in a kernel object wants > to call a function in the main part of the kernel it needs the address. > How can it get this target address? Relocations. > > When code is linked together into a single file it is possible to have > compilations have patched into them the offsets to functions or data from > other compilations. But this only works when the relative locations are > fixed. > > If you want different kernel objects to get random addresses when loaded > at run time then you _must_ have some way for the kernel object to call > back into the main kernel. It is possible to, at the C language level, > pass around structs holding pointers to functions and pointers to data. > But this does the same thing as relocations and it does it less efficiently.When a chunk of code is compiled with -fpic, function calls are produced with a special relocation type. When it is linked, all these calls are gathered into an indirect PLT (procedure linkage table). In userland, the PLT is dirtied at startup and varies depending on the random load address. But all the indirect calls are PC-relative to the PLT. eg: if the kernel bzero is at 0xc0201230, and we load a .ko file at 0xc100000 which has three "call bzero" references, then: -fpic case: all three calls to bzero will pc-relative "call" a slot in the PLT, which is resolved and created at "ld -shared" time, which will be run time relocated to "jmp 0xc0201230". ie: "call bzero@PLT" -> "jmp bzero" -> bzero() non-fpic case: each instance of the three "call bzero" will be relocated without making an indirect bounce through the PLT, which we don't need. ie: "call bzero" -> bzero() there would be three symbol lookups at .ko load time instead of one. The big difference (besides the loss of the %ebx register) is those extra memory hits to do a bzero(), that are paid for every single time. Meanwhile the non-pic case has an up-front cost of invoking some extremely unoptimized code at load time and never has the runtime overhead. Linux doesn't use 'ld -shared' format. They used something vaguely like what we did with the old LKM system, ie: running ld incrementally and loading the results. That was a long time ago, but they sure don't take the overhead of PLT/GOT/-fpic mode either. There's just no need. We provoke a warning on the gentoo tools on i386 because we simply used 'ld -shared' output as a container or transport. We use a different format by default on amd64, but the code is generated exactly the same way as on i386 and has exactly the same relocations in the same places. -- 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
<kpneal <at> pobox.com> writes:> ... > You can appeal to authority by saying the Gentoo Hardened developers said > such-and-such all you want, but it would be more useful for you to be able > to make specific technical arguments yourself. Saying "it could be a > problem" or "in the wild there may be" isn't useful. A valid technical > argument giving a mechanism for relocations to be exploited is all that > is needed for you to prove your point. > ...I have a question regarding security of FreeBSD kernel module loading and relocation. According to KLDLOAD(8): "...The kldload utility loads file.ko into the kernel using the kernel linker. ..." So, kernel module is loaded: # kldload /boot/kernel/foo.ko Here is my question: is foo.ko modified at this time ? Due to relocations ? The reason I ask about it is this Gentoo Hardened FAQ item: http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#paxnoelf "I keep getting the message: "error while loading shared libraries: cannot make segment writable for relocation: Permission denied." What does this mean?" I understand this is about .so and does not apply directly to .ko . But of interest to me is this: "... Text relocations are a way in which references in the executable code to addresses not known at link time are solved. Basically they just write the appropriate address at runtime marking the code segment writable in order to change the address then unmarking it. This can be a problem as an attacker could try to exploit a bug when the text relocation happens in order to be able to write arbitrary code in the text segment which would be executed. ..." Now, let me apply the above quoted paragraph to .ko and ask my question again, this time being more specific: are you doing any "marking" and "unmarking" of it at relocations and load time, thus creating an attack window opportunity ? jb
If there is malicious code in a kernel module, then discussions of relocations become moot. Sent from my Android 4.0 device. Please forgive any spelling or grammatical errors. On Apr 4, 2012 11:35 AM, "jb" <jb.1234abcd@gmail.com> wrote:> Peter Wemm <peter <at> wemm.org> writes: > > > ... > > There is no way to interfere because it is done outside of user space > > entirely, **after** the file has been copied out of the file system. > > You can do whatever you like to the file, but it has no effect because > > all the relocation is done in a private kernel copy. > > ... > > What if attack code (broadly understood) is part of module code, and is > based > on either or both of: > - hidden (as to meaning and reloc targets) arrangement of relocations > needed > - has an ability of (self) activation during load/link and *relocations* > process > already under the privilege of the kernel ? > > Is that possible at all ? > Would there be any protection against it (except giving up relocations as > an enabling vehicle) ? > > jb > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >