Apache OpenOffice (AOO) Bugzilla – Issue 47132
C++ UNO Bridges: Use executable memory for generated proxy code
Last modified: 2008-05-16 03:31:42 UTC
In bridges::cpp_uno::shared::VtableFactory::createBlock/flushCode, use executable memory for the code snippets (and thus for the vtables also, although this would not be necessary), and then generally use non-executable memory for the heap. (See, for example flushCode for msvc_win32_intel.) Some new function like rtl_allocateMemory(size, alloc_flags) is necessary in sal.
accepted
*** Issue 52428 has been marked as a duplicate of this issue. ***
See duplicate issue 52428 for additional information.
A useful resource for the kind of things that'll fail/warn on e.g. future RHEL-5 http://people.redhat.com/drepper/selinux-mem.html
Created attachment 33612 [details] our current linux specific patch
*** Issue 61537 has been marked as a duplicate of this issue. ***
retargeted
Created attachment 35062 [details] what we shipped as solution
As discussed in the thread at <http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=16366>, postponed until MHU offers appropriate functionality from rtl/alloc.h.
@mhu: Do you have an appropriate issue I can make this one dependent on?
Hi Stephan, you can add this issue to cws_src680_mhu12 (also intended to be integrated into OOo 2.0.3), and make it dependent on the issues that are registered for that cws (mainly #i23172# and #i57764# me thinks). Hope that helps, Matthias
@mhu: Note that I am on vacation Apr 22 -- May 7, so can only adapt the bridges code to any new rtl/alloc functionality before then.
Created attachment 35786 [details] Testcase demonstrating allocation of executable memory via rtl_arena_* functionality
mhu->sb: The proposed (testcase) implementation might not look as simple as possible, but in fact it is. This is so, b/c it clearly separates concerns: one piece of code (the "my_*" functions) provides executable memory (and returns it to the system), while the other piece of code (the "rtl_arena_*" functions) manages this memory, and allows to allocate and free it in user defined chunks (quanta).
For regression testing, use testtools/source/bridgetest/ (see <http://udk.openoffice.org/common/man/draft/tests.html>).
... but see issue 63543 for current problems of testtools/source/bridgetest/.
... for which the easiest workaround is to build testtools, then remove all lines from "begin re-declaration of ambiguous base interfaces" to "end re-declaration of ambiguous base interfaces" from testtools/<platform>/inc/test/testtools/bridgetest/XMultiBase6.hdl, and re-build testtools.
@cmc: If you would like to verify that the changes on CWS mhu12 indeed fix the executable memory problem on SELinux, that would be great.
@mhu: As discussed, please take care of this issue while I am on vacation. re-open issue and reassign to mhu@openoffice.org
reassign to mhu@openoffice.org
reset resolution to FIXED
This has now been verified (in a slightly modified revision, see below) on an Athlon 64 system, running Fedora Core 5 with SELinux enabled (Sun internal: of-1). The initial change in /bridges/source/cpp_uno/shared/vtablefactory.cxx had to be adapted again, similiar to what cmc proposed recently: an mmap (PROT_READ | PROT_WRITE | PROT_EXEC) will fail with "allow_execmem = false". Anon memory needs to be mmap()'d w/o PROT_EXEC, and lateron mprotected() to become executable. The apparently most clean solution (memory protection wise) is in cmc's 2nd patch (of Mar 20): allocate writeable memory, assemble the code snippets, then mprotect() to PROT_READ+PROT_EXEC. But, even that may fail when "allow_execmod = false" which would let the mprotect() call fail as well (though I haven't tested this myself). Anyway, the fix is verified to work under "allow_execmem = false" => verified.
*** Issue 64754 has been marked as a duplicate of this issue. ***
This Issue is 'Verified' and not updated in 1yr+, so Closing. A Closed Issue is a Happy Issue (TM). Regards, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~