Hello, Install phase of the ebuild fails the PAX way: [748522.496342] grsec: denied RWX mprotect of <anonymous mapping> by /mnt/portage_home/portage/www-client/firefox-48.0/work/firefox-48.0/ff/dist/bin/xpcshell[xpcshell:25672] uid/euid:0/0 gid/egid:0/0, parent /mnt/portage_home/portage/www-client/firefox-48.0/work/firefox-48.0/ff/_virtualenv/bin/python2.7[python:25664] uid/euid:0/0 gid/egid:0/0 [748522.496359] xpcshell[25672]: segfault at 0 ip 0000037a424686ef sp 000003e3bc7fd750 error 6 in libxul.so[37a3ee1d000+4f4f000] [748522.496372] grsec: Segmentation fault occurred at (nil) in /mnt/portage_home/portage/www-client/firefox-48.0/work/firefox-48.0/ff/dist/bin/xpcshell[xpcshell:25672] uid/euid:0/0 gid/egid:0/0, parent /mnt/portage_home/portage/www-client/firefox-48.0/work/firefox-48.0/ff/_virtualenv/bin/python2.7[python:25664] uid/euid:0/0 gid/egid:0/0
Created attachment 442692 [details] emerge --info
Same problem here. Reason: paxctl -v /var/portage/portage/www-client/firefox-48.0/work/firefox-48.0/ff/dist/bin/xpcshell PaX control v0.9 Copyright 2004,2005,2006,2007,2009,2010,2011,2012,2014 PaX Team <pageexec@freemail.hu> file /var/portage/portage/www-client/firefox-48.0/work/firefox-48.0/ff/dist/bin/xpcshell does not have a PT_PAX_FLAGS program header, try conversion Doing a paxctl -C followed by a paxctl -m on that xpcshell and restarting the emerge fixes the problem for me: After that, the emerge finishes successfully.
Same problem with the final firefox executable: Also lacks PT_PAX_FLAGS program header, also gets killed by PAX when started. Can be fixed in the same way.
(In reply to Klaus Kusche from comment #3) > Same problem with the final firefox executable: > Also lacks PT_PAX_FLAGS program header, also gets killed by PAX when started. > Can be fixed in the same way. If you are still using PT_PAX you are way behind the times, you should have switched to XATTR by now.
(In reply to Jory A. Pratt from comment #4) > If you are still using PT_PAX you are way behind the times, you should have > switched to XATTR by now. Well, as far as I remember, there was absolutely *no* message that PT_PAX is actually being dropped from Gentoo / from binutils now: There was no warning in the emerge log when emerging binutils, there was no eselect news message (that's what eselect news is for, isn't it?), there was just plain nothing. There should have been some warning! Now, I'm still fighting to get my system back to full functionality (because many PAX markings got silently dropped by emerges during the last few weeks after PT_PAX was silently removed from binutils, and migration to XATTR of course fails if there are no valid PT_PAX markings), to migrate it to XATTR (except for the missing markings, that was easy), and to redesign my backup and restore (which is the main reason I kept PT_PAX, my mixed-software backup and restore isn't XATTR transparent at all, because there are no independent and universally agreed standards how to backup XATTR in standard-conformant tar files, i.e. backing up with Schilling's tar and restoring with GNU tar or vice versa drops all XATTR's).
I always used xattrs but the build is failing for me anyway.
There isn't a chance that the /mnt/portage_home filesystem has xattr support missing from it, is there?
(In reply to Ian Stakenvicius from comment #7) > There isn't a chance that the /mnt/portage_home filesystem has xattr support > missing from it, is there? I can mark files with paxctl-ng, 'getfattr -n user.pax.flags' shows it right.
*** Bug 590926 has been marked as a duplicate of this bug. ***
Created attachment 443300 [details, diff] pax-mark xpcshell Please test and let me.
I have committed the change to main tree, it will take a bit to populate to the mirrors so please be patient.
(In reply to Jory A. Pratt from comment #10) > Created attachment 443300 [details, diff] [details, diff] > pax-mark xpcshell > > Please test and let me. It works normally, but still crashes if USE="pgo".
It seems that pgo build uses xpcshell before the install stage.
(In reply to Dmitry Safonov from comment #13) > It seems that pgo build uses xpcshell before the install stage. pgo is not officially supported at this time. Refer to other pgo bugs for mozilla products and leave comments and suggestions there. We have a dev who is looking to support PGO not sure how soon that will occur tho.
(In reply to Dmitry Safonov from comment #12) > (In reply to Jory A. Pratt from comment #10) > > Created attachment 443300 [details, diff] [details, diff] [details, diff] > > pax-mark xpcshell > > > > Please test and let me. > > It works normally, but still crashes if USE="pgo". Could you please provide a full build log and error message for the failure with USE=pgo. I don't have a hardened setup suitable to test this issue.
Created attachment 443476 [details] USE=pgo build log
(In reply to Andrew Savchenko from comment #15) > (In reply to Dmitry Safonov from comment #12) > > (In reply to Jory A. Pratt from comment #10) > > > Created attachment 443300 [details, diff] [details, diff] [details, diff] [details, diff] > > > pax-mark xpcshell > > > > > > Please test and let me. > > > > It works normally, but still crashes if USE="pgo". > > Could you please provide a full build log and error message for the failure > with USE=pgo. I don't have a hardened setup suitable to test this issue. The error is the same as the first one: [ 4352.041473] grsec: denied RWX mprotect of <anonymous mapping> by /mnt/portage_home/portage/www-client/firefox-48.0/work/firefox-48.0/ff/dist/bin/xpcshell[xpcshell:30934] uid/euid:250/250 gid/egid:250/250, parent /mnt/portage_home/portage/www-client/firefox-48.0/work/firefox-48.0/ff/_virtualenv/bin/python2.7[python:30908] uid/euid:250/250 gid/egid:250/250 [ 4352.041490] xpcshell[30934]: segfault at 0 ip 000003a9b4e35ec8 sp 000003e6a7425f90 error 6 in libxul.so[3a9ab1ca000+beff000] [ 4352.041506] grsec: Segmentation fault occurred at (nil) in /mnt/portage_home/portage/www-client/firefox-48.0/work/firefox-48.0/ff/dist/bin/xpcshell[xpcshell:30934] uid/euid:250/250 gid/egid:250/250, parent /mnt/portage_home/portage/www-client/firefox-48.0/work/firefox-48.0/ff/_virtualenv/bin/python2.7[python:30908] uid/euid:250/250 gid/egid:250/250
@hardened, is there any way to call pax-mark outside of ebuild scope? The problem with xpcshell is that it is an auxiliary tool that is is both build and executed during firefox build process. PGO is not the only case, tests will fail as well. To fix this properly I need to set "m" pax mark just after xpcshell is built, so pax-mark call from ebuild will not work. Looking at pax-mark source I see that there are nine(!) ways to do this depending on available tools and user-selected methods. And I can't just source eclass and call pax-mark within Makefile :( Do you have any tool to do this? Of course, I can port pax-mark code to a separate script, but this script will have to be in sync with eclass, which is a large long-term burden. If someone can point me to a sane way to use eclass outside of ebuild, I hear.
(In reply to Andrew Savchenko from comment #18) > @hardened, > > is there any way to call pax-mark outside of ebuild scope? > > The problem with xpcshell is that it is an auxiliary tool that is is both > build and executed during firefox build process. PGO is not the only case, > tests will fail as well. > > To fix this properly I need to set "m" pax mark just after xpcshell is > built, so pax-mark call from ebuild will not work. Looking at pax-mark > source I see that there are nine(!) ways to do this depending on available > tools and user-selected methods. And I can't just source eclass and call > pax-mark within Makefile :( Do you have any tool to do this? > > Of course, I can port pax-mark code to a separate script, but this script > will have to be in sync with eclass, which is a large long-term burden. If > someone can point me to a sane way to use eclass outside of ebuild, I hear. U can use paxmark.sh from sys-apps/elfix to mark it
Thanks!
Created attachment 443684 [details, diff] firefox-48.0-pax.patch @Dmitry, please test this patch. It should work for all cases (both with and without pgo). You'll need sys-apps/elfix installed (proper deps will be added in the tree if patch is correct). For testing please remove code introduced by patch 443300 (from comment 10) from your local ebuild. That code should not be needed with this patch, so I'd like to get a proper testing.
Created attachment 443726 [details] new patch build.log (In reply to Andrew Savchenko from comment #21) > Created attachment 443684 [details, diff] [details, diff] > firefox-48.0-pax.patch > > @Dmitry, please test this patch. It should work for all cases (both with and > without pgo). You'll need sys-apps/elfix installed (proper deps will be > added in the tree if patch is correct). > > For testing please remove code introduced by patch 443300 (from comment 10) > from your local ebuild. That code should not be needed with this patch, so > I'd like to get a proper testing. nsinstall from "../../../config/nsinstall -t -m 755 'xpcshell' '../../../dist/bin'" strips the markings just after paxmark.sh sets it; then the stripped version is used failing as before.
(In reply to Dmitry Safonov from comment #22) > nsinstall from "../../../config/nsinstall -t -m 755 'xpcshell' > '../../../dist/bin'" strips the markings just after paxmark.sh sets it; then > the stripped version is used failing as before. Are you using both PT_PAX and XATTR_PAX? Looks like nsinstall ignores xattr :/
XATTR it is :\
Created attachment 443734 [details, diff] firefox-48.0-pax.patch Ok, this time pax mark is set on xpcshell after it is copied to dist/bin; looks like both attributes are set correctly: paxctl-ng -v firefox-48.0/ff/dist/bin/xpcshell firefox-48.0/ff/dist/bin/xpcshell: PT_PAX : -em-- XATTR_PAX : -em-- Please test (and remove pax-mark command from the ebuild as well).
It works now. Thanks!
bircoph that is not how mozilla team works, the pgo build issue is a whole different bug, please open a new bug report add appropriate info there. We do not hijack or piggy back bug reports. Thank You.
(In reply to Andrew Savchenko from comment #25) > Created attachment 443734 [details, diff] [details, diff] > firefox-48.0-pax.patch > > Ok, this time pax mark is set on xpcshell after it is copied to dist/bin; > looks like both attributes are set correctly: > > paxctl-ng -v firefox-48.0/ff/dist/bin/xpcshell > firefox-48.0/ff/dist/bin/xpcshell: > PT_PAX : -em-- > XATTR_PAX : -em-- > > Please test (and remove pax-mark command from the ebuild as well). Patch is not something we can get landed upstream, I would prefer a simple check of toolchain for hardened feature and paxmark based on it. But as stated earlier new bug report please
(In reply to Jory A. Pratt from comment #27) > bircoph that is not how mozilla team works, the pgo build issue is a whole > different bug, please open a new bug report add appropriate info there. We > do not hijack or piggy back bug reports. Thank You. Jory, I fully agree with you that piggybacking of bugs is a bad practice. However, in this specific case both problems are just different manifestations of the very same issue: xpcshell (which is firefox auxiliary tool that is being used at _multiple_ places during build process) needs PaX marking on PaX enabled systems. Patch provided in comment #10 fixed one of symptoms, but not the whole issue as was reported by the user in comment #12. Please note that this issue is not strictly PGO specific, because tests are also affected, since they use xpcshell as well. So with the help of Dmitry's testing and Mangnus's help on pax marking I provided a patch to fix this problem once and for all possible cases. I can create a new bug for this, but I will have to close it right away as a duplicate of this bug, because they share the same reason. > (In reply to Jory A. Pratt from comment #28) > Patch is not something we can get landed upstream, I would prefer a simple > check of toolchain for hardened feature and paxmark based on it. But as > stated earlier new bug report please As I explained in comment #18, it is not possible to properly fix this issue only by ebuild modification. We have to use the patch. Since upstream doesn't officially support PaX setups (as well as most other upstreams), there is nothing wrong with carrying this patch in our patchset. Anyway this bug shouldn't stay as fixed, because stable guys ask to mark bugs as fixed only when they hit stable tree [1]. If there are no further objections, I'll apply proposed patch in a few days. [1] https://archives.gentoo.org/gentoo-project/message/8145cda3f9779caf0c41e328296ec178
