Summary: | app-editors/emacs-24.2 failed to emerge with a segmentation fault on hardened-sources-3.7.4-r1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | bsod |
Component: | Current packages | Assignee: | Emacs project <emacs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | avk, bog, graham, hardened-kernel+disabled, pageexec, releng |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 427888 | ||
Attachments: |
emacs build.log
Use the shell version of pax-utils.eclass |
Description
bsod
2013-02-12 17:46:52 UTC
Created attachment 338712 [details]
emacs build.log
Does building of emacs-23.4-r4 succeed? Can you build emacs-24.2 with a previous hardened kernel version? No emacs-23.4-r4 doesn't work either. I can't test another kernel because I can't restart this (server)machine all the time. The only reason I'm not using the stable hardened-sources is because they failed to build with an error. Maybe I can test it with another (older) hardened-kernel in some days... @hardened-kernel team: Can you reproduce this? It can be seen in the build.log that a "/sbin/paxctl -r temacs" is done, but temacs fails in unexec in spite of this. The kernel seems to be the problem. I updated to 3.7.6-hardened and emacs is emerging without error. 3.7.4 seems to be making a lot of problems as some other problems disappeared as well. Thanks for the hint. hardened-sources-3.7.5 and 3.7.6 both break emacs-24.2 here, unless I set randomize_va_space=0 (1 doesn't work, and my default is 2). Maybe there's some other PaX parameter I have that's causing it to fail? emacs-23.4-r4 didn't work for me either. I'm on stable amd64 with the hardened profile. Just an idea and a setting I changed from 3.7.4 to 3.7.6 ... do you use PAX_KERNEXEC_PLUGIN_METHOD_BTS or PAX_KERNEXEC_PLUGIN_METHOD_OR? I had the problems with 3.7.4 and PAX_KERNEXEC_PLUGIN_METHOD_OR, the problems disappeared when I switched to 3.7.6 and PAX_KERNEXEC_PLUGIN_METHOD_BTS. I had no opportunity to test this any futher though. (In reply to comment #7) > I had the problems with 3.7.4 and PAX_KERNEXEC_PLUGIN_METHOD_OR what problems exactly? that setting is for a kernel self-protection feature, it should not affect userland in any way... For example the bug this thread is all about. This was the only setting I was playing around with, everything else was from the gentoo hardening handbook. Everything is working for me since the upgrade to 3.7.6. Thats why I asked for that settings. It is very well possible that I'm on the wrong track. I figured out what the issue is for me. I'd switched over to XATTR_PAX_FLAGS=y, PT_PAX_FLAGS=n... And of course the patch for #411439 uses paxctl which only sets PT flags. Would it be possible to have the emacs build system prefer paxctl-ng to paxctl, if installed? Is paxctl-ng "standard" now? (No problems with PAX_KERNEXEC_PLUGIN_METHOD_OR here.) (In reply to comment #10) > Would it be possible to have the emacs build system prefer paxctl-ng > to paxctl, if installed? Sure. Prepare a patch and submit it to Emacs upstream. It's already too late for Emacs 24.3, but you may convince them to include it in 24.4. We can backport the changes to existing versions once they've been accepted upstream. (Thinking about it, our previous paxctl changes for Emacs submitted at http://debbugs.gnu.org/11398 will appear only in the next upstream release, namely 24.3. Extrapolating this, we'll likely be reiterating for paxctl-ds9 or paxctl-voy at the time of the 24.4 release. ;-) (In reply to comment #10) > I figured out what the issue is for me. I'd switched over to > XATTR_PAX_FLAGS=y, PT_PAX_FLAGS=n... And of course the patch for #411439 > uses paxctl which only sets PT flags. Would it be possible to have the > emacs build system prefer paxctl-ng to paxctl, if installed? Is paxctl-ng > "standard" now? > > (No problems with PAX_KERNEXEC_PLUGIN_METHOD_OR here.) Once the new eclass is in place, this bug will not happen. See bug #431092. (In reply to comment #12) > Once the new eclass is in place, this bug will not happen. See bug #431092. That's not right, since paxctl is called by the upstream build system. The emacs ebuilds don't inherit pax-utils.eclass. *** Bug 480526 has been marked as a duplicate of this bug. *** *** Bug 490626 has been marked as a duplicate of this bug. *** This is affecting the build of the admin-cd, ever since I switched my host to use XATTR_PAX_FLAGS. Created attachment 366582 [details, diff]
Use the shell version of pax-utils.eclass
It use the shell version of pax-utils.eclass instead of paxctl
it depend on sys-apps/elfix
(In reply to Magnus Granberg from comment #17) > Created attachment 366582 [details, diff] [details, diff] > Use the shell version of pax-utils.eclass > > It use the shell version of pax-utils.eclass instead of paxctl > it depend on sys-apps/elfix Can you submit this to Emacs upstream, please? Also, from the logic in paxmark.sh, the final emacs binary would end up with some extended attributes? (The Makefile does "$(PAXCTL) -zex emacs", with the intention to remove any previously set flags.) Hopefully fixed in emacs-24.3-r2 and emacs-23.4-r6. No revbump, because it is a build failure and installed files are unchanged. Please test. For reference, patches are here: http://git.overlays.gentoo.org/gitweb/?p=proj/emacs-tools.git;a=commit;h=88a257278a1a85b82884b84d634f73f65c40b9c2 (In reply to Ulrich Müller from comment #20) > Please test. <jmbsvicetto> ulm: >>> Installing (136 of 269) app-editors/emacs-24.3-r2 <jmbsvicetto> ulm: :) Reported upstream: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16343 Fixed in bzr upstream: http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/115867?compare_revid=115865 |