Bug 177390 - app-emulation/e-uae crashed with hardened-sources.
|
Bug#:
177390
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: dholm@gentoo.org
|
Reported By: yaroslav.isakov@gmail.com
|
|
Component: Hardened
|
|
|
URL:
|
|
Summary: app-emulation/e-uae crashed with hardened-sources.
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-05-07 00:01 0000
|
Hello, I found that app-emulation/e-uae need "pax-mark m e-uae" with
hardened-sources, because of this:
PAX: execution attempt in: <anonymous mapping>, 08357000-0aa23000 08357000
PAX: terminating task: /usr/bin/e-uae(e-uae):30268, uid/euid: 1000/1000, PC:
0aa08000, SP: 5b25079c
PAX: bytes at PC: 50 51 52 53 8b 05 90 cd 44 08 0f a2 89 05 8c cd 44 08 89 1d
PAX: bytes at SP-4: 0a3071d0 08245858 00000000 00000000 00000000 00000000
0a3071d4 0a3071d8 0a3071d0 0a3071d0 0a3071d0 0833fb4d 00000001 08245954
0a3071d8 0a3071d4 00000000 00000000 00000000 00000000 00000000
My emerge --info is in bug #177387
David, Peter - this just needs a simple call to pax-mark as suggested by
Yaroslav.
----
inherit ... pax-utils
...
src_install() {
pax-mark m ${D}/usr/bin/uae
...
}
----
should do the trick. I don't have Amiga images so I haven't tried it myself,
but I fully expect that to work; it's normal for emulators to do just-in-time
compilation for example, which would need the mprotect() restriction relaxed.
Kevin, I do not have hardened sources to test. Could you commit it by yourself?
Of course, if you wish, I can commit and you test but I think it's much easier
to fix and test in one place... :)
ok; done, although I don't have kick.rom to try properly.
Yaroslav, give it half an hour, then please sync up and check for us.
Thanks, it works. BTW, does it really need trampolines emulation (I see --mxE-
in output of scanelf)?
May be not, but as far as I understood it's how code works now.
It's probably from binutils which set flags based on some (unclean for me)
reasons. Maybe it's wrong? I paxctl -e e-uae and it's works as usual...
The upstream build explicitly sets '-Wa,execstack' everywhere, which is why it
ends up with the execstack marking. Whether that's because upstream believe it
enables executable heap or not, I don't know (it certainly doesn't for us).
Some systems don't differentiate between executable stack and executable heap;
although for the pure threat model there's no difference
The software doesn't contain any trampolines, so it's safe to reset to -e
(adding '-Wtrampolines' to CFLAGS will show this; grep the build log for
"generating trampoline" - comment out the 'strip-flags' in the ebuild to see it
in action, otherwise it'll be stripped out).
Ahem - didn't finish the sentence:
...although for the pure threat model there's no difference, in practice
forbidding executable stack while allowing executable heap does raise a barrier
to stack overflow exploits.
Yes, you're right. So, maybe "pax-mark me e-uae"?
I had a further thought - it may be that it needs the -Wa,execstack for systems
using RedHat's execshield, like RHEL (execshield is a sort of poor-man's PaX,
in our view - although RedHat obviously disagree with us!). Resetting -E to -e
won't affect execshield (which uses the PT_GNU_STACK header, that we leave
alone), so I'll tweak it accordingly.