Re: Processed: Re: Bug#188475: /usr/bin/localedef confilicts with PAX
> Maybe. Mailing to xxxxxx@bugs.debian.org sends to the only package
> maintainer - the above To: and Cc: is the complete list.
it was a direct mail to him, not to any debian address (in hindsight,
i should have cc'd everyone... oh well ;-).
> > the quick solutions were already listed (chpax, grsec ACLs), i'd
> > also add rewriting the code to not use nested functions (if memory
> > serves me right, in this case it's only one instance and can be
> > safely turned into a normal function call).
>
> Do you think to modify glibc or gcc?
for the above, i meant glibc (localedef to be more precise).
> The nested function is the famous compiler extension. If the
> trampoline technique is the fundamental problem, I suggest you to see
> the detail with "info gcc". If you can't get the original paper,
> please tell me.
i know how it works, i even added emulation of it in PaX (one has
to enable it in the kernel config and on individual binaries as
well though, and it is a bad idea for security). the problem with
the gcc trampoline implementation is that it assumes that certain
memory regions (such as the stack) are executable, whereas nothing
guarantees it (e.g., on ia-64/linux the stack is not executable even
in the mainline kernel, not to mention sparc64 where the ABI mandates
it). this leads to the generic problem though:
> Well, it seems not to fix easily.
> Some Java compilers generate its code in non text region for the
just as a sidenote, Sun's JVM has other issues than runtime code
generation: apparently in an attempt to not use inline assembly
in their source code, they've put some FPU initilization code into
the data segment - you can guess how far it gets under PaX.
> processor optimization and the match code circumstance in each
> occasion; it's also conflicts and it's difficult to detect its
> behavior...
the proper approach for generating code at runtime is to explicitly
request such (writable/executable) memory then write the code there
then make it read-only/executable (all this to minimize the time of
exposure where an attack could abuse it). besides ld.so i know of no
program that does this properly and hence i decided to enforce strict
read-only/executable pages in the kernel itself.
fixing this in the apps is not terribly difficult but it will have
a performance impact (3 system calls) and in the gcc trampoline case
would totally nullify its usefulness. personally i would like to see
even more changes in how writable/executable pages are handled, but
that's slightly beyond POSIX (new protection flags to mmap/mprotect)
so i guess they would never be accepted.
in any case, i can totally understand if you don't want to deal
with these problems in debian, it affects few people (and it's
unlikely to change in the future). my suggestion would be to direct
these users to Trusted Debian and put the workarounds into some
HOWTO or FAQ.
Reply to: