From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8553 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Results of static analysis with clang static analyser Date: Wed, 23 Sep 2015 20:34:42 -0400 Message-ID: <20150924003442.GG17773@brightrain.aerifal.cx> References: <20150923193809.GE17773@brightrain.aerifal.cx> <1443038571.23868.17.camel@inria.fr> 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 1443054898 10438 80.91.229.3 (24 Sep 2015 00:34:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Sep 2015 00:34:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8565-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 24 02:34:57 2015 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 1ZeuUz-0006r6-5N for gllmg-musl@m.gmane.org; Thu, 24 Sep 2015 02:34:57 +0200 Original-Received: (qmail 1997 invoked by uid 550); 24 Sep 2015 00:34:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1970 invoked from network); 24 Sep 2015 00:34:54 -0000 Content-Disposition: inline In-Reply-To: <1443038571.23868.17.camel@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8553 Archived-At: On Wed, Sep 23, 2015 at 10:02:51PM +0200, Jens Gustedt wrote: > Am Mittwoch, den 23.09.2015, 15:38 -0400 schrieb Rich Felker: > > On Tue, Sep 22, 2015 at 10:58:55PM -0700, Khem Raj wrote: > > > Hi All > > > > > > I have run scan-build on musl-git and here are results > > > > > > http://busybox.net/~kraj/scan-build-2015-09-22-224330-15962-1/ > > > > At a quick glance, most of these seem to be cases of assuming system > > calls do not store to the objects they receive pointers to. > > Some of them, yes. But the one in __memalign seems to have secret > knowledge that it may access header information preceeding the pointer > that was received from malloc. I have no idea what a compiler in a > freestanding environment is allowed (or not) to assume in that case. malloc is not reserved in a freestanding environment. LLVM/clang used to get this wrong and badly broke musl, but it was fixed sometime around 3.4 or 3.5 I think. > Perhaps it would be cleaner to have a malloc_helper function that > returns the veritable start of the reserved chunk and then the user > interface wrappers such as malloc and friends return that address plus > the necessary offset. It might, but that probably add an extra layer of call. I'll see if I can come up with a reasonable way to do something like this when I get around to overhauling malloc, though, since it seems useful. > > This makes > > them false positives, but if llvm is actually making that same > > assumption when optimizing that could be a bug in itself. Hopefully > > it's just treating it as "unknown" whether the object is stored to, > > rather than "definitely not accessed". > > The one in pthread_create I always struggle with. I remember that I > had myself once convinced (or was it you?) that the bad case can't > happen, but I was not able to reproduce the argument spontaneously. >From my perspective, this one is simply a bug in the static analysis. At line 218, pointer arithmetic was performed on `stack` to get `tsd`. If `stack` were null this would be UB, and if `stack` is not null then you cannot get a null pointer without the arithmetic having invoked UB, so you can conclude that `tsd` is not null. Of course such UB could happen if inputs are invalid (e.g. attribute containing a size larger than the actual size of the stack) or if internal state is invalid (e.g. if the computation of `need` wraps), so maybe it's useful to have this analysis take place. Rich