Happy Holidays to all developers still reading bug reports at this time~~! I just debugged a pypy crash on a box running on Hardened Gentoo amd64; the reason is that MPROTECT is not disabled on the pypy executable. Since the ebuilds do not check for "jit" USE flag and turn off MPROTECT in that case, weird MemoryError's (actually mmap() calls failing with -EPERM) are going to happen to the users who explicitly turned on JIT to emerge pypy. Clearly not so smooth an experience for PyPy users running on PaX... We should inherit pax-utils and pax-mark the pypy-c executable in src_install, if USE flag jit is set. I can prepare the patch if you don't really have the time (actually I myself is busy preparing for end-term exams, haha), thanks in advance.
@hardened: Ok to add pax-mark m here?
A pax related error, probably the same: emerge fails during the install phase of pypy on a hardened machine. Therefore I created a binary on a non-hardened gentoo and transfered the package to the very hardened box. Obviously installing works, yet running doesn't. A "memory error" is reported - the very same error due to which install fails. I had to manually run paxctl -pemrxs /usr/bin/pypy-c2.0 in order to get pypy to work, as mentioned in the gentoo hardened faq.
(In reply to comment #2) > A pax related error, probably the same: > > emerge fails during the install phase of pypy on a hardened machine. > Therefore I created a binary on a non-hardened gentoo and transfered the > package to the very hardened box. Obviously installing works, yet running > doesn't. A "memory error" is reported - the very same error due to which > install fails. > > I had to manually run > > paxctl -pemrxs /usr/bin/pypy-c2.0 > > in order to get pypy to work, as mentioned in the gentoo hardened faq. Just checked the pypy ebuild for this installation problem, and yes the error is the same. In pypy-2.0_beta1.ebuild:103-110 the fresh PyPy binary is being executed for the pickles, which would immediately die with -EPERM the moment it tries to do JIT. PS: Actually only MPROTECT needs to be disabled for the executable, that is -m. In my case PyPy is used to run the development branch of a Django site, and I have not yet seen any breakage with all the other PaX features on.
Created attachment 347738 [details, diff] Apply "pax-mark m" on the generated pypy executable Apply with patch -p5 < pypy-2.0_beta2.ebuild-pax-fix in /usr/portage/dev-python/pypy
+ 08 May 2013; Mike Gilbert <floppym@gentoo.org> pypy-2.0_beta2.ebuild: + Disable MPROTECT if jit is enabled, bug 448818.
