| Summary: | sys-devel/gcc-4.7.0: breaks hardened-sources PaX gcc plugins | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Anthony Basile <blueness> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | anarchy, gentoo, gentoo, hardened-kernel+disabled, hardened, kensington, kfm, martin, mybighello, n.schlumberger, pageexec, powerman-asdf |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 390247, 409315 | ||
|
Description
Anthony Basile
2012-04-24 22:53:01 UTC
*** Bug 413121 has been marked as a duplicate of this bug. *** Explain what you need to happen here. Do you have code written that you want applied? If we disable building GCC with C++ to enable the use of the PaX plugins, what, if any, C++ plugins will that break? (In reply to comment #2) > If we disable building GCC with C++ to enable the use of the > PaX plugins, what, if any, C++ plugins will that break? Are there any packages at all in Gentoo besides hardened-sources which make use of compiler plugins (no matter C or C++)? (In reply to comment #2) > Explain what you need to happen here. Do you have code written that you > want applied? If we disable building GCC with C++ to enable the use of the > PaX plugins, what, if any, C++ plugins will that break? None of the PaX gcc plugins are in C++ so nothing should break there. I don't know, however, if there are other packages that need C++ plugins. (In reply to comment #2) > Explain what you need to happen here. Do you have code written that you > want applied? If we disable building GCC with C++ to enable the use of the > PaX plugins, what, if any, C++ plugins will that break? Hi Ryan, i recently posted an explanation here: http://archives.gentoo.org/gentoo-hardened/msg_5899f5e48948f26f2915748a261dedaf.xml basically we're not talking about any patches to gcc here, but rather a policy decision (ideally across distros ;) whether to build gcc 4.7 with gcc or g++ (for 4.8+ there will be no choice to make from what i read, g++ will be mandatory). as for plugins written in C++ (e.g., dragonegg), they already had to be able to build and link against gcc/g++ built by gcc since that's how gcc 4.5/4.6 are built (they too however have to detect the new gcc 4.7 build style so as to avoid extern "C" for pure C++ builds). in any case, as i indicated in my gentoo-hardened mail, i'll fix the C++ build issue with the kernel but hardened users would probably appreciate at least a USE flag to build gcc 4.7 with gcc instead of g++ in the meantime (speaking of USE flags, one day i'd like to have 'debug' enabled for gcc to pass --enable-checking=assert,misc,rtl,rtlflag,runtime,tree to configure ;). i don't think we want a dedicated USE flag for that sort of thing. it'll lead to even more ways to compile gcc, and we have too many as it stands (the bootstrap logic for example). best to fix the code. It's probably a good idea to provide a function in toolchain-funcs that determines the compiler gcc was built using. We already provide the option to not build with g++ when USE="-cxx" so version tests will be unreliable. seems to me that the reasonable thing would be to make the gcc plugin layer not care. the point of the plugins are to generally insulate themselves from version-to-version issues, and to make it easier to load & execute on the fly. so this is a bug that should be filed upstream: the symbol convention of gcc plugins should not be dependent upon how gcc itself was built. seems like it's more of an oversight with gcc plugins being so new. (In reply to comment #8) > seems to me that the reasonable thing would be to make the gcc plugin layer > not care. the point of the plugins are to generally insulate themselves > from version-to-version issues, and to make it easier to load & execute on > the fly. the plugin layer as such doesn't really exist, it's basically a way for gcc to load shared libraries that can then access any of its otherwise visible symbols (which is about *everything* not statically declared), it's nothing like say glibc with well defined exported/versioned symbols. so plugins are always expected to be compiled for a given gcc version, there's no guarantee for binary plugin portability (and even with source code one needs the occasional gcc version dependent #ifdef). > so this is a bug that should be filed upstream: the symbol convention of gcc > plugins should not be dependent upon how gcc itself was built. seems like > it's more of an oversight with gcc plugins being so new. problem is that it's not really feasible to force C symbol bindings for all the symbols available to plugins (short of compiling with gcc instead of g++, that is) 'cos that's pretty much 'everything' as mentioned above and adding extern "C" to all of them is not going to fly... (In reply to comment #9) i'd like to think this particular issue is an oversight. let's take it upstream and see what happens rather than speculate. If users are ready sacrifice security that comes with these plugins, they can also workaround this by "export DISABLE_PAX_PLUGINS=1"'ing prior to make. Just saying. this issue has since been fixed in PaX (gcc/g++ autodetection). (In reply to PaX Team from comment #12) > this issue has since been fixed in PaX (gcc/g++ autodetection). In which version of hardened-sources it was fixed? It looks like I've this issue on current stable amd64: hardened-sources-3.10.1-r1, gcc-4.7.3-r1 fail to rebuild (previously built using gcc-4.6.3) nvidia-drivers with this error: make[4]: *** [/var/tmp/portage/x11-drivers/nvidia-drivers-319.49/work/kernel/nv-acpi.o] Error 1 cc1: error: cannot load plugin /usr/src/linux-3.10.1-hardened-r1/tools/gcc/colorize_plugin.so /usr/src/linux-3.10.1-hardened-r1/tools/gcc/colorize_plugin.so: undefined symbol: pp_base_set_prefix cc1: error: cannot load plugin /usr/src/linux-3.10.1-hardened-r1/tools/gcc/structleak_plugin.so /usr/src/linux-3.10.1-hardened-r1/tools/gcc/structleak_plugin.so: undefined symbol: register_attribute (In reply to Alex Efros from comment #13) > In which version of hardened-sources it was fixed? when i said it was ;), over a year ago, 3.10 should definitely work. > It looks like I've this issue on current stable amd64: > hardened-sources-3.10.1-r1, gcc-4.7.3-r1 fail to rebuild (previously built > using gcc-4.6.3) nvidia-drivers with this error: > > make[4]: *** > [/var/tmp/portage/x11-drivers/nvidia-drivers-319.49/work/kernel/nv-acpi.o] > Error 1 > cc1: error: cannot load plugin > /usr/src/linux-3.10.1-hardened-r1/tools/gcc/colorize_plugin.so > /usr/src/linux-3.10.1-hardened-r1/tools/gcc/colorize_plugin.so: undefined > symbol: pp_base_set_prefix 1. what gcc version was your linux tree (and hence, the gcc plugins) built with? 2. what gcc version are you building the nvidia drivers with? my guess is that there's a discrepancy between the two in which case you'll have to stick to one gcc version, as plugins are not meant to be binary compatible between gcc versions (upstream decision, not mine). in general, if you switch gcc versions between compiling your kernel and external modules, you'll have to rebuild the gcc plugins with the new gcc. (In reply to PaX Team from comment #14) > 1. what gcc version was your linux tree (and hence, the gcc plugins) built with? > 2. what gcc version are you building the nvidia drivers with? Thanks, you was right - I didn't recompiled kernel after upgrading gcc. Maybe it makes sense to mention this issue on http://www.gentoo.org/doc/en/gcc-upgrading.xml ? *** Bug 489752 has been marked as a duplicate of this bug. *** *** Bug 589902 has been marked as a duplicate of this bug. *** |