On Jan 20, 2005, at 15:28, Charlie Brady wrote:

>> One of the features of openwall is stack protection.  I'm getting this
>> when I try to boot into a 2.4.29 kernel with openwall hardening
>> enabled:
>>
>> Security: return onto stack from 0x0804812c to 0xbffffea0 running as
>> UID 0, EUID 0, process runit:1
>> Security more returns onto stack, logging disabled for a minute
>>
>> I can manage to make the kernel boot, but runit isn't running and it's
>> consuming 100% cpu in my vmware test machine.
>>
>> I have two ideas that may be causing the problem, and not being a
>> kernel person I don't really know for 100% which it is:
>>
>> 1) the Non-executable user stack area part of owl
>> 2) the enforce RLIMIT_NPROC on execve(2)
>>
>> I have a feeling that it's #1 tho.
>
> Why do you have that feeling? What gives you these two ideas? Do you 
> see
> any actions from runit before the "return onto stack" message?

Well, for one, it's explicitly stating runit (ie. process runit:1).  
For two, runit is starting, but when runit should be switching to stage 
2, I keep getting these errors and pretty much nothing is happening.

The kernel boots, the fs is mounted, and the first error is before the 
traditional initscripts, which runit runs, is done.  Those initscripts 
execute fine without error, but when runit should be switching to stage 
2, all I get are these errors being reported with CPU climbing.

> You might run "strace runit-init" in place of "runit", although I'm not
> sure what chaos that might cause.

Well, it is in vmware so doesn't really matter... =)  I'll just take a 
snapshot first.  The fact that the kernel is pretty much pointing out 
runit each time leads me to believe it's, well, runit.  I'm not sure 
what runit is doing when it's entering it's stages, but whatever it is 
doing might be what is causing the owl-patched-kernel to freak out.

BTW, I just compiled and upgraded to runit 1.2.1 and see the same 
behaviour.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}