Bugzilla Bug 201250

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.