Hi!
On Fri, Apr 03, 2009 at 12:43:26AM +0200, [email protected] wrote:
> hmm, i don't get it. are you saying that with MPROTECT enabled in the
> kernel, bash fails to start when run as init, but works otherwise?
>
> hmm, so nothing stands out, and only pid=1 is ever affected? i've never seen
> such a failure mode ;).
Yep. Me too. I can try other application, but if both bash and runit-init
affected I think there little sense in trying other.
So, yeah, the question is, how to debug PaX while kernel starting process N1?
Or how to prove process N1 has nothing with this bug?
To resume, what we've now:
Fact 1: previous kernel (2.6.27-hardened-r8) doesn't hangs
Fact 2: kernel hang after "Freeing unused kernel memory:"
* so I suppose it failed to start process N1
Fact 3: kernel compiled without MPROTECT doesn't hangs
* so I suppose it's something related to PaX ...
* or some very unique hardware issue
Fact 4: kernel loaded with init=/bin/bash hangs in same way
* so it's unlikely issue with runit-init
Fact 5: paxctl -m for init command (/sbin/runit-init or /bin/bash) fix issue
* so there workaround exists which doesn't lower overall server security
Fact 6: /bin/bash works just fine without paxctl -m after boot
* so it has nothing with usual PaX work
Fact 7: this issue happens on one of several similar (if no equal) servers
* buggy hardware or some conflict (there IRQ differences between servers)?
I think best way to find out what happens - add debug prints into PaX code
which executes while starting process N1.
--
WBR, Alex.
