Hi all,
In the C++ UNO bridges, we need executable memory for the genereated
vtables, see <http://udk.openoffice.org/issues/show_bug.cgi?id=47132>.
(Strictly speaking, it is not the memory for the vtables themselves that
needs to be executable, but rather the memory for the generated code
thunks the vtable entries point to. However, it is easiest to use a
single chunk of memory for a set of vtables together with the associates
code thunks.)
At the moment, this memory is allocated with new[], which---depending on
platform---might or might not forward to rtl_allocateMemory. (It is a
coincidence that new[] is used instead of directly calling
rtl_allocateMemory, and to simplify the following discussion we can
assume that this has been changed already, to always use
rtl_allocateMemory.) A further detail is that this memory is never
freed again, but rather kept until program termination.
The previous paragraph implies that currently (all) the memory managed
by rtl_allocateMemory must be executable, which is problematic. This
can be fixed in one of (at least) three ways:
1 Once the memory has been obtained from rtl_allocateMemory, make the
pages it lies on executable. Pro: local change in C++ UNO bridges, no
new interface in rtl/alloc.h needed. Con: makes too much memory
executable, as the memory obtained from rtl_allocateMemory will
typically not span full pages (i.e., the same pages are also used by
rtl_allocateMemory to fulfil other requests for memory that need not be
executable).
2 Add rtl_allocateExecutableMemory to rtl/alloc.h, which internally
uses the same logic as rtl_allocateMemory, but works on a second set of
memory, independent of the original set of memory managed by plain
rtl_allocateMemory (and the second set of memory would be executable,
while the original set would not be). Pro: general solution, re-uses
existing program logic, does not make too much memory executable. Con:
extends rtl/alloc.h interface, complicates rtl/alloc.
3 Exploiting the fact that the executable memory in question is never
freed, add a simple, special-purpose (executable) memory allocator to
bridges/source/cpp_uno/shared. It would work similar to
rtl_allocateMemory by using mmap (or equivalent), but would be much
simpler since it would not have to keep track of a free list: if there
is enough space left at the end of the last obtained mmap area, use
that; otherwise, obtain a new mmap area. Pro: local change in C++ UNO
bridges, no new interface in rtl/alloc.h needed, does not make too much
memory executable. Con: can't think of one.
I favour the third way, and intend to implement it. Note that this
still does not address the issues at
<http://people.redhat.com/drepper/selinux-mem.html>, but could be
changed in the future to use the double mapping approach outlined there.
Any comments?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
