From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10292 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: abort() fails to terminate PID 1 process Date: Mon, 4 Jul 2016 23:07:38 -0400 Message-ID: <20160705030738.GS15995@brightrain.aerifal.cx> References: <20160620100443.GV22574@port70.net> <20160620194110.GM10893@brightrain.aerifal.cx> <20160703135846.GF15995@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1467688076 26435 80.91.229.3 (5 Jul 2016 03:07:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2016 03:07:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10305-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 05 05:07:56 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bKGiI-0002kd-TZ for gllmg-musl@m.gmane.org; Tue, 05 Jul 2016 05:07:55 +0200 Original-Received: (qmail 30007 invoked by uid 550); 5 Jul 2016 03:07:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 29978 invoked from network); 5 Jul 2016 03:07:50 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10292 Archived-At: On Mon, Jul 04, 2016 at 03:37:35PM +0200, Igmar Palsenberg wrote: > > > > Whether you realize it or not, what you're saying is equivalent to > > saying that it's UB for a process that runs as pid 1 to call abort(). > > There is no basis for such a claim. > > > > A vague "pid 1 is special" rule (which the standard does not support > > except in a few very specific places where an implementation-defined > > set of processes are permitted to be treated in specific special ways) > > does not imply "calling a function whose behavior is well-defined can > > legitimately lead to runaway code execution if the pid is 1". > > But doesn't "bevavior is well-defined" also imply that that function > behaves as it should ? If it doesn't, doesn't the "well-defined" no longer > apply ? I call it UB in this case. "Behavior is well-defined" means the specification tells what it does and does not leave it implementation-defined, unspecified, or undefined -- neither by explicitly saying so, nor by omission. > The standard also says a process can't ignore a SIGKILL, but on pid 1, it > has no effect. I pretty much call that UB myself. You keep using that word. I do not think it means what you think it means. If anything what you're arguing is that the Linux kernel has a bug, since the behavior of raising SIGKILL is specified and Linux does not do what the spec says (for pid 1). That does not mean it's undefined but rather that the implementation is behaving contrary to the defined behavior. Rich