according to the PaX team, "precompiled header support (PCH) is not compatible with ASLR, or rather, there's a botched up attempt at handling it but it's not compatible with SEGMEXEC" When I used EXTRA_ECONF="--disable-precomp-headers" I was able to successfully compile wxGTK-2.6.4.0-r1 (I suspect the same works for 2.6.3.3). This seems to be controlled by the PCH useflag in the newer (hardmasked) ebuilds. This needs to be added to the stable ebuild. Also, perhaps the ebuild should check if PaX is enabled to disable PCH. Reproducible: Always Steps to Reproduce: 1. Use a kernel with PaX enabled. 2. emerge wxGTK (2.6.3.3 or 2.6.4.0-r1, maybe others) FAIL 3. Try again, with EXTRA_ECONF="--disable-precomp-headers" Success :-) Actual Results: Compile succeeds only with EXTRA_ECONF="--disable-precomp-headers" Expected Results: There should be a useflag for toggling PCH. Also, it would be good if the ebuild could check for PaX and disable PCH.
reassigning to hardened. if this is relevant to security, please assign back to us.
Is this limited to PaX-ASLR only or could mainlines kernel.randomize_va_space also cause problems?
(In reply to comment #2) > Is this limited to PaX-ASLR only or could mainlines kernel.randomize_va_space > also cause problems? it's not so much related to randomization but to the halved address space and a bad choice in gcc. what happens is that the data structures/files used by PCH contain absolute addresses, i.e., they are not relocatable (it's a design choice that noone's fixing afaik). this means that gcc has to mmap the PCH files at a fixed address but using MAP_FIXED is dangerous since it could replace some already existing mapping, so they just use a hinted mmap request and see if they get the mapping there. PaX/ASLR doesn't honour this hint (as it's just a hint) and maps the file at a random address regardless. so far so good, gcc sees this and attempts to deal with the situation by trying to use a per-arch hardcoded address that, in their wisdom, is most likely unmapped (after all most of the gcc address space is unused so it's not unreasonable to guess such a big enough hole). except the choice for i386 happens to fall above the SEGMEXEC_TASK_SIZE limit, therefore it fails under SEGMEXEC. so there are two possible fixes: disable the use of PCH if SEGMEXEC is active on gcc, or choose another hardcoded address for i386 (perhaps by keeping the current one and trying a second, SEGMEXEC friendly one when that fails). short term, you can just disable PCH on this package, but longer term patching gcc would be better.
As wxWindows team member, I don't see what we should be doing here. How are we unique in triggering this problem? Could potentially all PCH using packages be affected? We had all this discussion over half a year ago with PaX and I thought we had this settled.. :) We now currently have it behind a pch USE flag, but we might want to reconsider at some point..
(In reply to comment #4) > As wxWindows team member, I don't see what we should be doing here. How are we > unique in triggering this problem? Could potentially all PCH using packages be > affected? yes, all are. > We had all this discussion over half a year ago with PaX and I thought we had > this settled.. :) heh, i knew i must have seen this already but didn't remember ;-). > We now currently have it behind a pch USE flag, but we might want to reconsider > at some point.. it's fine for now, but longer term gcc should be fixed to have a fallback address that work under SEGMEXEC as well.
(In reply to comment #5) > (In reply to comment #4) > > As wxWindows team member, I don't see what we should be doing here. How are we > > unique in triggering this problem? Could potentially all PCH using packages be > > affected? > > yes, all are. > > > We had all this discussion over half a year ago with PaX and I thought we had > > this settled.. :) > > heh, i knew i must have seen this already but didn't remember ;-). > > > We now currently have it behind a pch USE flag, but we might want to reconsider > > at some point.. > > it's fine for now, but longer term gcc should be fixed to have a fallback > address that work under SEGMEXEC as well. > (In reply to comment #5) > (In reply to comment #4) > > As wxWindows team member, I don't see what we should be doing here. How are we > > unique in triggering this problem? Could potentially all PCH using packages be > > affected? > > yes, all are. > > > We had all this discussion over half a year ago with PaX and I thought we had > > this settled.. :) > > heh, i knew i must have seen this already but didn't remember ;-). > > > We now currently have it behind a pch USE flag, but we might want to reconsider > > at some point.. > > it's fine for now, but longer term gcc should be fixed to have a fallback > address that work under SEGMEXEC as well. > The current stable ebuild doesn't listen to the pch USE flag, perhaps this should be changed. Currently, all wxGTK ebuilds that listen to the pch USE flag are hardmasked. With an ebuild that does listen to the pch USE flag, will it default to not using pch, at least on hardened systems? Is there a reason not to do this? Yes, fixing gcc does seem like the ideal solution, does another bug need to be filed for that, or what?
wxGTK-2.6.4.0-r2 and wxGTK-2.8.7.1 have a pch USE flag, but they are masked until eselect-wxwidgets gets keyworded properly. I have no problem with adding the flag to 2.6.4.0-r1 as well, as it doesn't affect the final product IIUC. Would this be satisfactory?
Adding that flag and having hardened use.mask the pch USE= flag seems the ideal solution for now.
just for reference, the gcc code in question is gcc/config/host-linux.c:linux_gt_pch_get_address() and the unfortunate define is #elif defined(__i386) # define TRY_EMPTY_VM_SPACE 0x60000000 this can/will also fail on kernel configs where the user/kernel split is not 3:1 but lower.
okay, USE flag added to wxGTK-2.6.4.0-r1. should i close this or do you guys want it open?
For now we are not going to use.mask the pch flag as the support it depends on is an optional config option in the kernel. we wont enable it by default or anything. If it continues to be a problem it will use.masked. Closing bug as FIXED (avoiding bug spam). thanks a lot guys.
