177390 2007-05-07 00:01 0000 app-emulation/e-uae crashed with hardened-sources. 2007-05-09 20:55:57 0000 1 1 1 Unclassified Gentoo Linux Hardened unspecified All Linux RESOLVED FIXED P2 normal --- 1 yaroslav.isakov@gmail.com dholm@gentoo.org hardened@gentoo.org pva@gentoo.org yaroslav.isakov@gmail.com 2007-05-07 00:01:35 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 kevquinn@gentoo.org 2007-05-07 10:19:01 0000 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. pva@gentoo.org 2007-05-07 13:05:05 0000 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... :) kevquinn@gentoo.org 2007-05-07 16:23:09 0000 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. yaroslav.isakov@gmail.com 2007-05-07 21:35:30 0000 Thanks, it works. BTW, does it really need trampolines emulation (I see --mxE- in output of scanelf)? pva@gentoo.org 2007-05-08 08:47:54 0000 May be not, but as far as I understood it's how code works now. yaroslav.isakov@gmail.com 2007-05-08 21:20:28 0000 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... kevquinn@gentoo.org 2007-05-08 21:25:09 0000 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). kevquinn@gentoo.org 2007-05-08 21:26:44 0000 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. yaroslav.isakov@gmail.com 2007-05-08 21:51:40 0000 Yes, you're right. So, maybe "pax-mark me e-uae"? kevquinn@gentoo.org 2007-05-09 20:14:00 0000 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. yaroslav.isakov@gmail.com 2007-05-09 20:55:57 0000 Thanks