[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160703202448.GK15995@brightrain.aerifal.cx>
Date: Sun, 3 Jul 2016 16:24:49 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: abort() fails to terminate PID 1 process
On Sun, Jul 03, 2016 at 10:20:46PM +0200, Laurent Bercot wrote:
> On 03/07/2016 22:01, Rich Felker wrote:
> >No. Halting the system safely (which kernel panic does) is completely
> >different from runaway wrong-code execution, and the only reason we
> >don't have runaway wrong-code execution right now is because I built
> >in the for(;;) safety in case termination failed.
>
> Halting the system, no matter how safely, is also completely different from
> cleanly terminating the aborting process (while not impacting other processes
> as is supposed to be guaranteed by Unix). At this point, we're wildly outside
> the realm of specification anyway, and I find it acceptable to say that pid 1
> abort (or any kind of death for that matter) is UB. Your choice of
> implementation for abort() is good and safe, but I think it's just QoI,
> not something you're bound to do by a standard.
Halting the system when init exits is functionally equivalent to
having a hidden parent process provided by the OS that performs a halt
when its child (pid 1) exits. There's nothing fishy going on there. On
the other hand, having random code start executing would be clearly
wrong well beyond mere QoI.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
