1 |
On 03/09/2011 04:03 AM, pageexec@××××××××.hu wrote: |
2 |
> On 8 Mar 2011 at 15:55, Mike Frysinger wrote: |
3 |
> |
4 |
>> On Tue, Mar 8, 2011 at 3:49 PM, Anthony G. Basile wrote: |
5 |
>>> Nothing to say that Mike hasn't already said. pipacs knows about this |
6 |
>>> but what can he do? Good luck with upstream glibc. Next time I speak |
7 |
>>> with pipacs I can bring it up, see if anything is changing. I doubt it. |
8 |
>> |
9 |
>> if there is a real bug in glibc that drepper is ignoring, that doesnt |
10 |
>> mean we cant merge it into Gentoo's glibc. hence open a bug in |
11 |
>> bugs.g.o with the patch for me to review. |
12 |
> |
13 |
> it's not just a glibc bug, it's the whole shit concept of GNU_STACK and |
14 |
> all it brings with it, see my Nth explanation here: |
15 |
> |
16 |
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611195#10 |
17 |
> |
18 |
> i can (and do) disable GNU_STACK handling in PaX, but userland is out of |
19 |
> my reach (well, technically i could do even that by hacking the page cache |
20 |
> but that's too ugly to even consider). so as far as i'm concerned, you have |
21 |
> the following choices in order of preference: |
22 |
> |
23 |
> 1. disable GNU_STACK processing (mostly in ld.so i think) |
24 |
> - this should solve all current and future problems but it won't be a |
25 |
> one-liner patch |
26 |
> |
27 |
> 2. fix at least the mprotect return value checks in ld.so |
28 |
> - the patch is in the glibc bugzilla |
29 |
> - this fixes only the segfaults, it won't let these app to work under PaX, |
30 |
> - actually, you could modify the patch and on the first mprotect failure |
31 |
> you can just not attempt the write to that relro variable (and not bother |
32 |
> with the second mprotect obviously), that should then let the library load |
33 |
> too (elsewhere gentoo already fixed the stack mprotect code and ignores |
34 |
> *its* mprotect failures under PaX) |
35 |
> |
36 |
> 3. execstack -c affected libs/binaries from portage |
37 |
> - at install time we can detect (and already do, iirc) RWE GNU_STACK headers |
38 |
> - if such a GNU_STACK header is really needed, i.e., the given app/lib does |
39 |
> need an executable stack (nested function trampolines are emulated under |
40 |
> PaX so they just need EMUTRAMP enabled on the app) then disable MPROTECT |
41 |
> on the app (and for libs, all apps using the given lib) |
42 |
> - if the RWE GNU_STACK header is a false positive, either fix the app (if we |
43 |
> have source code) or execstack -c for binaries. |
44 |
> - this is again quite some work |
45 |
> |
46 |
> |
47 |
|
48 |
For what its worth, I've written some proof of concept code for this, a |
49 |
library which needs execstack because of a trampoline which is |
50 |
dlopen'ed. I put the tarball on my dev space: |
51 |
|
52 |
http://dev.gentoo.org/~blueness/pocs/trampoline-poc.tgz |
53 |
|
54 |
If you do |
55 |
|
56 |
CFLAGS+="-DTRAMPOLINE" make |
57 |
make install |
58 |
make dltest |
59 |
|
60 |
you'll hit the above problem. If you then do |
61 |
|
62 |
strace ./dltest |
63 |
|
64 |
you'll see it dies because of mprotect. |
65 |
|
66 |
Note: there's other stuff here because I'm using this in a class I'm |
67 |
teaching. |
68 |
|
69 |
-- |
70 |
Anthony G. Basile, Ph.D. |
71 |
Gentoo Developer |