runit-init and PAX MPROTECT

runit-init and PAX MPROTECT

[Alex Efros]

Hi!

I'm not sure is it runit issue or is it possible to fix in runit source,
but, thing is, it's already second time when runit-init conflict with
PAX MPROTECT.

Short story:
1.5 years ago, after upgrading (Gentoo Linux)
    from sys-kernel/hardened-sources-2.6.28-r6
    to   sys-kernel/hardened-sources-2.6.28-r7
kernel hangs while boot when tried to start /sbin/runit-init.
Actual reason was segfault in runit-init because of PAX MPROTECT,
which can be worked around by completely switching off PAX MPROTECT in
kernel or switching it off individually for /sbin/runit by
    paxctl -m /sbin/runit-init
In some later kernel this was fixed.
But yesterday it happens again after upgrading
    from sys-kernel/hardened-sources-2.6.32-r9
    to   sys-kernel/hardened-sources-2.6.32-r22
As far as I understood, this doesn't mean it's 100% bug in PAX - I think
PAX protection was improved, become more strict, and so disallow some
operations which was accepted by older PAX.

Long story:
http://www.mail-archive.com/gentoo-hardened@lists.gentoo.org/msg02464.html
http://www.linux-archive.org/gentoo-hardened/443398-2-6-28-hardened-r7-hangs-before-starting-sbin-init.html

I think this is critical enough issue because kernel hang after upgrade
while booting remote servers is very bad. If there any chance to fix this
issue in runit source, that would be best.

Probably if it was possible to run runit-init under strace, it become
clear which syscall is now disallowed by PAX MPROTECT. But runit-init
behave differently when it executed not as process N1 (and doesn't trigger
PAX MPROTECT in this case), so it's impossible to run it under strace.
Maybe if runit will be patched to fork `strace -p 1` right after starting
as process N1 this helps. If Gerrit provide such runit version to me - I
will test it with that kernel.

-- 
			WBR, Alex.