Some discussion first :) bridges/source/cpp_uno/gcc3_linux_intel/cpp2uno.cxx uses 'new' to allocate memory into which it then writes code for execution. 'new' memory only has executable permission due to the inadequacy of the pre-"NX bit" intel architecture, so it works by accident more than by design. PaX kernels highlight this as they implement NX behaviour, whereby the heap is by default non-executable. Future kernels may make use of the NX bit in newer architectures to set heap data non-executable by default, requiring either mprotect() or mmap() to be used to obtain executable heap data. Execshield (RedHat) systems may also be affected, if openoffice is run with the execshield variant of NX protection. The fix is to use either mprotect() or mmap() to get executable heap memory. The rest of openoffice does this via the rtl_allocateMemory function provided in rtl/alloc.{c,h}. Luckily there's an example already present in the x86_64 code bridges/source/cpp_uno/gcc3_netbsd_intel/cpp2uno.cxx which makes things simpler, so the fix is to obtain the memory in the same way. Other systems that are similarly affected are solaris_intel, solaris_sparc, freebsd_intel, linux_powerpc, linux_sparc, macos_powerpc (basically everything except netbsd_intel, linux_s390 and linux_x86-64). Of particular note is that linux_x86-64 already uses the rtl_memoryAllocate function, so the amd64 arch should be unaffected. That leaves arches x86, ppc and sparc that could benefit from a fix. Also bridges/source/cpp_uno/gcc3_linux_intel/code.s has no .note.GNUstack section, which leads libgcc3_uno.so to be marked as needing executable stack, although I think code.s does not require executable stack.
Created attachment 78415 [details] copy of call.s - for verification that it indeed does not need executable stack attached here for easy reading - anyone please confirm this doesn't need executable stack :)
@Kevin: Isn't this something you should report upstream? As this is a general problem and nothing Gentoo-specific I think this should be discussed in OOo Issuezilla.
Created attachment 78418 [details, diff] add GNU-stack marking to asm, and change 'new' to call to rtl_allocateMemory in cpp2uno.cxx for linux intel This patches just the linux_intel (i.e. x86) code. This is a quick patch that should work, however upstream may prefer it to look more like the x86_64 code. Result is that the C++ to UNO bridge should work on PaX systems with just 'm', without this it needs 'psm' which is unnecessarily broad, especially since SSP isn't compatible with OOo. I've compiled the individual objects and shared library ok with this patch, but it'll take me a while to build the whole of openoffice.
Created attachment 78419 [details] Updated patch application patch (!) This replaces files/2.0.1/gentoo-2.0.1.diff since it's much simpler that way than providing a patch to a patch.
(In reply to comment #2) > @Kevin: Isn't this something you should report upstream? Yes; I figured I'd post it here to make sure I'm not talking garbage before bugging upstream :)
Just for the record: I've built OOo with your patch, looks good to me.
Thanks; built successfully here as well (takes my little machine a bit longer!) I need to work out something that actually uses the cpp2uno bridge to test what I've done, I don't know if I have anything...
@Kevin: Just a reminder to file this upstream, to get some feedback there. Otherwise I'm a little reluctant to add this to our ebuild, as I've not got that in-depth knowledge to see if it actually breaks something ;)
Filed at http://www.openoffice.org/issues/show_bug.cgi?id=61537
Kevin, I've added myself to the upstream bug, so closing this bug here, best to keep it in one place
The upstream bug I raised (http://www.openoffice.org/issues/show_bug.cgi?id=61537) has been marked a duplicate of http://www.openoffice.org/issues/show_bug.cgi?id=47132; changed the URL to reflect this. The assignee has set the target to 2.0.3, currently planned for May 2006.
