I've designed an enhanced check which can detect if xfree is compiled by hardened-gcc, but with forced propolice disabled through hcc. You can still have -fstack-protector in CFLAGS. It makes nvidia drivers work on hardened system. I don't know since which version of hcc this format of output exists, you should check it. I know it works at least for 2.4.2 and 2.4.4.
Created attachment 20263 [details, diff] xfree-4.3.0-r3.ebuild.patch
Created attachment 20269 [details, diff] xfree-4.3.0-r3.ebuild.patch v2 The problem isn't caused by propolice, but by et_dyn. Changing the check.
Still can't get it right, changing summary.
the reason why modules do not work with hardened-gcc in xfree is that the hardened-gcc demands xfree to be built without module support, this is no kernel module stuff, it is a proprietary load mechanism of xfree itself. look for DoLoadServer=NO in the ebuild or something like that. hppa even needs this always because the load mechanism is borked on this arch. the DoLoadServer=NO prevents modules like nvidia core drivers to load. if you cannot accept that, do not use hardened-gcc. The reason we need to do this is because under PaX kernels, which is what the hardened-gcc was designed for (!), you will not even be able to run xfree in generic module mode but instead would need to chpax it anyway if you had this load module mechanism active. i think its for your own good. thanks for your attention, Alex
hmmm... Thank you for your explanation. So the culprit is propolice-enabled kernel. So probably this is why I got duplicate symbols on loading the modules even with propolice/et_dyn disabled. I can live with that on this machine, I was just checking if it would be feasible to harden my terminals. (Anyway, I'm using -fstack-protector on these, only et_dyn is missing) Resolving CANTFIX.
what makes you think that propolice is kicking xfree by any means into doing this or that? i am talking about the PaX MPROTECT feature (do not get confused with the mprotect() system call here!). propolice is needed for linear stack overflow protection, it does not care about the proprietary module load mechanisms of programs. PaX however does. and this is what we did: if users have hardened-gcc, they care about secure systems and want to employ a PaX kernel with etdyn and propolice enabled binaries. so the reason we decided to remove the LoadServer mechanism from XFree86 when the user has hardened-gcc was simple: only few users have the nvidia modules active and yes, even they can be told not to use them ;-) dont misunderstand this as a propolice issue or something like that, we had quite a lot of trouble with propolice in the past times and i made my mistakes but i think its all solved in 2.4.5 2.4.6 and the hopefully soon to be implemented patches for the glibc containing propolice now instead of libgcc. anyway, i hope you understood it fully now :-)
I've got some small patches here that could use a little porting to the gentoo, that would allow us to have etdyn plus a LoadAbleServer if anybody is interested in testing/porting. The patch changes the xfree's default behavior from an elfloader to a dlloader like in freebsd.
diff -uNr xc.old/config/cf/host.def xc/config/cf/host.def --- xc.old/config/cf/host.def Thu Jan 1 01:00:00 1970 +++ xc/config/cf/host.def Mon Oct 13 14:29:04 2003 @@ -0,0 +1,6 @@ +#define DoLoadableServer YES +#define MakeDllModules YES given these two options that can also be added to the ebuild the usual way: if has_version ">=sys-devel/hardened-gcc-1.2"; then einfo "setting DoLoadableServer to NO for PaX and compiler for etdyn building" # this is good for a pax kernel to load the xfree server without the specific module support # that normally prevents xfree from being memory protected, pappy # it only breaks some people using external nvidia core modules and such, but this is not avoidable echo "#define DoLoadableServer Yes" >>config/cf/host.def echo "#define MakeDllModules Yes" >>config/cf/host.def fi the first one reenables the mod loader the second one changes the proprietary loading of objects into dlopen() of natural .so, this way PaX does not kill it now the question is: 1) who really does need this 2) who knows how insecure it is or may be in future exploits 3) what impact does it have to hardened-gcc compiling a secure by default userland make your wishes, until then i will not add it to the ebuild. thanks to solar for pointing out the technical fix (by Peter Busser from Adamantix)
