From owner-svn-src-all@freebsd.org Fri May 25 18:47:04 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DBCAEF0F4A for ; Fri, 25 May 2018 18:47:04 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0091E6E342; Fri, 25 May 2018 18:47:03 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w4PIl07D047013; Fri, 25 May 2018 11:47:00 -0700 (PDT) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w4PIl09V047012; Fri, 25 May 2018 11:47:00 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201805251847.w4PIl09V047012@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r334199 - head/usr.sbin/bhyve In-Reply-To: <20180525183403.i3bt2npfc3fq2cgf@mutt-hbsd> To: Shawn Webb Date: Fri, 25 May 2018 11:47:00 -0700 (PDT) CC: araujo@freebsd.org, Brooks Davis , svn-src-head@freebsd.org, Eitan Adler , svn-src-all@freebsd.org, src-committers Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 18:47:04 -0000 -- Start of PGP signed section. > On Sat, May 26, 2018 at 02:26:33AM +0800, Marcelo Araujo wrote: > > 2018-05-26 2:21 GMT+08:00 Brooks Davis : > > > > > On Sat, May 26, 2018 at 01:56:28AM +0800, Marcelo Araujo wrote: > > > > 2018-05-26 1:44 GMT+08:00 Brooks Davis : > > > > > > > > > On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote: > > > > > > On Sat, May 26, 2018, 1:11 AM Eitan Adler > > > wrote: > > > > > > > > > > > > > On 25 May 2018 at 08:23, Marcelo Araujo > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, May 25, 2018, 11:11 PM Brooks Davis > > > > > wrote: > > > > > > > >> > > > > > > > >> On Fri, May 25, 2018 at 02:07:05AM +0000, Marcelo Araujo wrote: > > > > > > > >> > Author: araujo > > > > > > > >> > Date: Fri May 25 02:07:05 2018 > > > > > > > >> > New Revision: 334199 > > > > > > > >> > URL: https://svnweb.freebsd.org/changeset/base/334199 > > > > > > > >> > > > > > > > > >> > Log: > > > > > > > >> > Fix a memory leak on topology_parse(). > > > > > > > >> > > > > > > > > >> > strdup(3) allocates memory for a copy of the string, does > > > the > > > > > copy > > > > > > > and > > > > > > > >> > returns a pointer to it. If there is no sufficient memory > > > NULL > > > > > is > > > > > > > >> > returned > > > > > > > >> > and the global errno is set to ENOMEM. > > > > > > > >> > We do a sanity check to see if it was possible to allocate > > > > > enough > > > > > > > >> > memory. > > > > > > > >> > > > > > > > > >> > Also as we allocate memory, we need to free this memory > > > used. > > > > > Or it > > > > > > > >> > will > > > > > > > >> > going out of scope leaks the storage it points to. > > > > > > > >> > > > > > > > > >> > Reviewed by: rgrimes > > > > > > > >> > MFC after: 3 weeks. > > > > > > > >> > X-MFC: r332298 > > > > > > > >> > Sponsored by: iXsystems Inc. > > > > > > > >> > Differential Revision: https://reviews.freebsd.org/ > > > D15550 > > > > > > > >> > > > > > > > > >> > Modified: > > > > > > > >> > head/usr.sbin/bhyve/bhyverun.c > > > > > > > >> > > > > > > > > >> > Modified: head/usr.sbin/bhyve/bhyverun.c > > > > > > > >> > > > > > > > > >> > > > > > > > > ============================================================ > > > > > ================== > > > > > > > >> > --- head/usr.sbin/bhyve/bhyverun.c Fri May 25 01:38:59 2018 > > > > > > > >> > (r334198) > > > > > > > >> > +++ head/usr.sbin/bhyve/bhyverun.c Fri May 25 02:07:05 2018 > > > > > > > >> > (r334199) > > > > > > > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt) > > > > > > > >> > c = 1, n = 1, s = 1, t = 1; > > > > > > > >> > ns = false, scts = false; > > > > > > > >> > str = strdup(opt); > > > > > > > >> > + assert(str != NULL); > > > > > > > >> > > > > > > > >> Using assert seems like an odd choice when you've already added > > > a > > > > > > > >> failure path and the strsep will crash immediately if assert is > > > > > elided. > > > > > > > > > > > > > > > > > > > > > > > > Just to make a better point, I had the same discussion about > > > > > assert(3) in > > > > > > > > another review, we don't do NDEBUG even for RELEASE. > > > > > > > > > > > > > > IMHO we only use assert for asserting things ought to never be > > > false > > > > > > > except in buggy code. Using assert for handling is poor practice. > > > > > > > > > > > > > > > > > > > Again, in this case we are using it all over the place and we must > > > > > replace > > > > > > it. Also we should document it in somewhere perhaps in the assert(3) > > > > > > otherwise myself and others will keep using it. If you use find, not > > > only > > > > > > myself is using it to check strdup! So what is the suggestion to > > > handle > > > > > > assert(3)? Deprecated it? > > > > > > > > > > Code that uses assert() in place of error handling is wrong and should > > > > > be fixed. assert(condition) means that condition must never happen > > > > > and if it does a bug has occurred (or the programmers assumptions are > > > > > wrong). In this case failure would not be due to a bug, but do to > > > > > resource exhaustion which is expected to be handled. > > > > > > > > > > > > > I agree with you! We have plenty of place that use strdup(3) without > > > check > > > > the errno ENOMEN return; so do you think would be better bypass a errno > > > > ENOMEN without check it and have a crash, or better abort(3) using > > > > assert(3) in case we have no memory available to allocated the memory > > > for a > > > > copy of a string? > > > > > > The correct code here would be one of: > > > > > > str = strdup(opt); > > > if (str == NULL) > > > goto out; > > > > > > > No, it is not the correct code! If we go out and free(str) we have nothing > > to free, because we even didn't allocated memory for str. > > Hey Marcelo, > > I've authored this commit, which fixes the issues Brooks brought up > (and with which I agree): > > https://github.com/HardenedBSD/hardenedBSD/commit/9c05b8def2c33e3889430cc2f54be0402a257366 > > Thanks, And as the author of the function in question I ALSO agree that this fix by Shawn should be commited. Thank you Shawn, only a few hundred more like this in bhyve(8) to fix now.... -- Rod Grimes rgrimes@freebsd.org