The only reproduction we were able to perform injected via a BMC soft poweroff 
being triggered.

This then called into kernel/reboot.c (orderly_poweroff where the schedule_work 
was performed) utilizing the

usermodehelper during the run_cmd /sbin/poweroff.

On 02/14/2018 09:44 AM, Laurent Bercot wrote:
>> When PID=0 in early kernel_init, PID=1 has a skeleton running, this 
>> detection is not
>> the Busybox /sbin/init, but a place holder for when the real Busybox 
>> /sbin/init is do_execve'd
>  Are you saying the kernel could spawn a /sbin/reboot process *before*
> kernel_init execs into the userspace init?
>  If it's the case (and Denys' test will verify it), it's violently out
> of spec. There should be no other userspace processes present before
> init, and if there are, the behaviour is totally undefined, and things
> should very much be expected to fail. It is basically impossible to
> program under Unix if you cannot assume there is a pid 1 present that
> will reap zombies.
>  It would be worth it to report the situation to the kernel maintainers
> so they make sure the spawning of userspace processes (triggered by
> soft-poweroff or anything else) is deferred until after /sbin/init has
> been do_execve()'d.
> -- 
>  Laurent

busybox mailing list

Reply via email to