It seems that mednafen needs MPROTECT disabled, indeed when it is enabled mednafen won't run with SNES games and I get: [38798.794485] PAX: execution attempt in: /usr/games/bin/mednafen, dbc8af000-dbc905000 0075a000 [38798.794493] PAX: terminating task: /usr/games/bin/mednafen(mednafen):9553, uid/euid: 1000/1000, PC: 0000000dbc902580, SP: 000003075b49cce8 [38798.794507] PAX: bytes at PC: 48 89 26 48 8b 27 58 48 89 6e 08 48 89 5e 10 4c 89 66 18 4c [38798.794519] PAX: bytes at SP-8: 0000000000000000 0000000dbc3a4d0d 0000000dbeea0a20 89eaaee9334e1400 0000000000000001 0000000dbc377408 000003075b49cd24 000003075ea11fe3 00000000bc9df4f0 89eaaee9334e1400 000000000000bb9e This seems to happen with SNES games only. No problem with other console games. "paxctl-ng -m /usr/games/bin/mednafen" solves the problem. The issue is the same with all the mednafen versions I've tried: 0.9.32, 0.9.28 (both from the Portage Tree) and 0.9.36.4 (from my own overlay). Reproducible: Always
suggest a patch since I don't have a hardened system to test on.
(In reply to Mr. Bones. from comment #1) > suggest a patch since I don't have a hardened system to test on. Right now i can't even get it to build because of a -Wunused-but-set-variable which is just a warning but at least on the hardened specs dies. So if we want this working on hardened you'd have to patch out the following pce.cpp:146:16: warning: variable ‘dummy_ne’ set but not used [-Wunused-but-set-variable] int32 dummy_ne; That should make our hardened gcc happy, but then you have to make the hardened kernel happy. You'd had 'inherti pax-utils' and then in src_install(), after `emake DESTDIR="${D}" install` you'd add pax-mark -m "${D}"/usr/games/bin/mednafen. @Scall, since you've been doing this on your overlay ebuilds, add the above and I'll review and either me or Mr Bones will commit.
Oops sorry, its not dying on that but this: vdc.cpp: In function ‘void PCE_Fast::MixBGSPR_x86(uint32, const uint8*, const uint16*, uint32*)’: vdc.cpp:1080:1: error: bp cannot be used in asm here }
(In reply to Anthony Basile from comment #3) > Oops sorry, its not dying on that but this: > > vdc.cpp: In function ‘void PCE_Fast::MixBGSPR_x86(uint32, const uint8*, > const uint16*, uint32*)’: > vdc.cpp:1080:1: error: bp cannot be used in asm here > } Acutally I just read that asm and wow. They're trying to clobber ebp which is just so wrong. Its the bottom of the stack pointer and you can't use it to store some value. I don't get why but I'll try to use some segment register and pray that it works. I think the check against this sort of abuse of ebp started with gcc 4.8. So you probably compile this with an earlier version. It certainly isn't going to fly with anything recent.
Created attachment 396362 [details, diff] Use gen purpose r8 rather than rbp on x86_64 This should work on amd64. x86 is a bit trickier.
(In reply to Anthony Basile from comment #4) > I think the check against this sort of abuse of ebp started with gcc 4.8. > So you probably compile this with an earlier version. Yes, I've always used GCC 4.7.3 for Mednafen because of bug #524914. Now the latest Mednafen 0.9.38.1 ebuild in the Portage Tree solves that issue, so probably would make sense to remove the older ebuilds, since those mednafen versions are really old. The MPROTECT issue is still present with mednafen 0.9.38.1 anyway.
Created attachment 397076 [details, diff] mednafen-0.9.38.1.ebuild.diff The ebuild should be modified as in the attached diff (I've taken the zsnes ebuild as example). Tested on my Gentoo Hardened box.
(In reply to Scall from comment #7) > Created attachment 397076 [details, diff] [details, diff] > mednafen-0.9.38.1.ebuild.diff > > The ebuild should be modified as in the attached diff (I've taken the zsnes > ebuild as example). Tested on my Gentoo Hardened box. This is a "cheap" fix but for something like this its fine. The better way is to fix the asm. The ebuild belongs to games, so let's see what they have to say.
(In reply to Anthony Basile from comment #8) > (In reply to Scall from comment #7) > > Created attachment 397076 [details, diff] [details, diff] [details, diff] > > mednafen-0.9.38.1.ebuild.diff > > > > The ebuild should be modified as in the attached diff (I've taken the zsnes > > ebuild as example). Tested on my Gentoo Hardened box. > > This is a "cheap" fix but for something like this its fine. The better way > is to fix the asm. > > The ebuild belongs to games, so let's see what they have to say. @games ping. Scall's ebuild is fine. Commit?
too bad pax-mark doesn't die by itself on EAPI=5 but oh well. Should be fixed now. thanks for the patch and bug report.
(In reply to Mr. Bones. from comment #10) > too bad pax-mark doesn't die by itself on EAPI=5 but oh well. Should be > fixed now. thanks for the patch and bug report. people not using hardened would fall back on scanelf which unfortunately dies silently. of course this can be fixed, but since scanelf is already used in lots of places, adding this behaviour might break something else and so it is a significant job to add the correct exit code to trigger die().
