On 03/09/2011 04:03 AM, [email protected] wrote:
> On 8 Mar 2011 at 15:55, Mike Frysinger wrote:
>
>> On Tue, Mar 8, 2011 at 3:49 PM, Anthony G. Basile wrote:
>>> Nothing to say that Mike hasn't already said. pipacs knows about this
>>> but what can he do? Good luck with upstream glibc. Next time I speak
>>> with pipacs I can bring it up, see if anything is changing. I doubt it.
>>
>> if there is a real bug in glibc that drepper is ignoring, that doesnt
>> mean we cant merge it into Gentoo's glibc. hence open a bug in
>> bugs.g.o with the patch for me to review.
>
> it's not just a glibc bug, it's the whole shit concept of GNU_STACK and
> all it brings with it, see my Nth explanation here:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611195#10
>
> i can (and do) disable GNU_STACK handling in PaX, but userland is out of
> my reach (well, technically i could do even that by hacking the page cache
> but that's too ugly to even consider). so as far as i'm concerned, you have
> the following choices in order of preference:
>
> 1. disable GNU_STACK processing (mostly in ld.so i think)
> - this should solve all current and future problems but it won't be a
> one-liner patch
>
> 2. fix at least the mprotect return value checks in ld.so
> - the patch is in the glibc bugzilla
> - this fixes only the segfaults, it won't let these app to work under PaX,
> - actually, you could modify the patch and on the first mprotect failure
> you can just not attempt the write to that relro variable (and not bother
> with the second mprotect obviously), that should then let the library
> load
> too (elsewhere gentoo already fixed the stack mprotect code and ignores
> *its* mprotect failures under PaX)
>
> 3. execstack -c affected libs/binaries from portage
> - at install time we can detect (and already do, iirc) RWE GNU_STACK
> headers
> - if such a GNU_STACK header is really needed, i.e., the given app/lib does
> need an executable stack (nested function trampolines are emulated under
> PaX so they just need EMUTRAMP enabled on the app) then disable MPROTECT
> on the app (and for libs, all apps using the given lib)
> - if the RWE GNU_STACK header is a false positive, either fix the app (if
> we
> have source code) or execstack -c for binaries.
> - this is again quite some work
>
>
For what its worth, I've written some proof of concept code for this, a
library which needs execstack because of a trampoline which is
dlopen'ed. I put the tarball on my dev space:
http://dev.gentoo.org/~blueness/pocs/trampoline-poc.tgz
If you do
CFLAGS+="-DTRAMPOLINE" make
make install
make dltest
you'll hit the above problem. If you then do
strace ./dltest
you'll see it dies because of mprotect.
Note: there's other stuff here because I'm using this in a class I'm
teaching.
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
