From owner-freebsd-arch@freebsd.org Sat May 26 08:10:00 2018 Return-Path: Delivered-To: freebsd-arch@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 E4A77F6D2CB for ; Sat, 26 May 2018 08:09:59 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 626A686CEB for ; Sat, 26 May 2018 08:09:59 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 1CC6BF6D2CA; Sat, 26 May 2018 08:09:59 +0000 (UTC) Delivered-To: arch@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 ECD5FF6D2C8 for ; Sat, 26 May 2018 08:09:58 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D44086CE9 for ; Sat, 26 May 2018 08:09:58 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yw0-x241.google.com with SMTP id i201-v6so2445462ywe.6 for ; Sat, 26 May 2018 01:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TJbCd9anqR2I1ENrdlIWToWr5xKmNo7Mp3WHl8+jFHo=; b=cmvaU5/XUj7PatG+IVwfk1YmEPJqw2+Nf4vMW3XaKhMu94rYzvJRweI6+3m0nNMMaW aDglaNiumS8ph4Pt9yLN/Rvz8cO2pwha5Xisn8raGt3bm6uAEK98Kc9MzkhLbOZ3ecDn WB8BZt0mLtK6r2qNIvXgLejGACXa35cRfiGqrN5cAoIRrRDkC6NdENB54yhEc/h8XBCB 65v34N7n/i0vnPIHMvbPxGJsxtSkGblN7IyBfw8N94PGQp1+/jEkv1QAOesWNzuFELKA HVeIfWuJaZffDgxPw62AjT2c/5Voaf7x+GUT91dfHBUjLO9zJ/lqsLK+Mwgtl+L9njNa I8TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TJbCd9anqR2I1ENrdlIWToWr5xKmNo7Mp3WHl8+jFHo=; b=coSNF/UbGKhNmWUUzmTB2ypCwjPvpaHLQvsuF8Q2VP6iqGTL85WjE2XnMGiF2sbGqq NIcTnck7L73DQI8PhJvIHyesMgl8xRHUOa7Kl0S+2tmXCHw1/U81KAMLcE4p7Ihtd4kr 8RNJ5dyv47/FEWN/D/dYi29dvW5TDFcD/VHpokp3JXVHqKl6N6hsWdVPldygN8//EcbU 1wzvSvJikdjfnSrs5zXmADa4yxWd4sGlRMRxc+msLqu6B0TRGDApLwFjndNWbDk4jtyq u8cStg5comYkDJ3zckeD/plYm08kLASiP64Dk+/R+qMBry/Opt81uUr5UDkT7Kw0IU3d PDXQ== X-Gm-Message-State: ALKqPwfPWkJiFhMK92Q3pvT2n0wkfr8AwefKyleayDOBWh9FJ/mi59ku 5eIk6s2ybYSMB97HGO3hN4ycMH1qXRlHtxbCEdkLRw== X-Google-Smtp-Source: ADUXVKJ65855vsh74AbfsFG7++2Q9kja5lzu6qnTnY4EfEOUvOXdUVzH0Z4d4Dr1C4ymyeuIgRO0xwcirQ1UJA43Ws0= X-Received: by 2002:a0d:ff85:: with SMTP id p127-v6mr3088040ywf.41.1527322197745; Sat, 26 May 2018 01:09:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:3894:0:0:0:0:0 with HTTP; Sat, 26 May 2018 01:09:57 -0700 (PDT) In-Reply-To: <4514.1527319154@critter.freebsd.dk> References: <4514.1527319154@critter.freebsd.dk> From: Oliver Pinter Date: Sat, 26 May 2018 10:09:57 +0200 Message-ID: Subject: Re: To assert() or not to assert(), that is not really a question... To: Poul-Henning Kamp Cc: "arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 08:10:00 -0000 On Saturday, May 26, 2018, Poul-Henning Kamp wrote: > When I started writing Varnish Cache, on of the first decision was > that I would pepper the source code with asserts even "pointless" > ones, and I did to the order of 10% of all source file lines, and > it is probably the best decision I have ever made. > > The primary effects of all the asserts is that we get crash-dumps > from the earliest possible point in time the trouble could be > spotted. For a process which can rutinely have several thousands > threads, that is what makes debugging possible in the first place. > > The secondary effect is that the sheer number of asserts means > that crashes can almost always be isolated to a very small stretch > of code based on the assert location. > > The one benefit from all the asserts I had not anticipated is that > they almost always prevent program bugs from turning into information > leakage vulnerabilities: We stop before we send wrong data out. > > The biggest impact of all the asserts however, is that Varnish Cache > went 11 years while moving a very large fraction of all HTTP traffic > on the net, without a major security issue. > > When we finally got our first big CVE, it was not a remote excution, > an information leak or anything horrible bad: It was a "harmless" > DoS caused by a wrong assert test, but a DoS is still pretty bad > news when so much traffic goes through Varnish. > > I think FreeBSD needs to learn from Varnish Cache's experience: > We should have far more asserts in FreeBSD. > > We already have a "private" assert facility in the kernel, and > people should simply use it more. This private assert facility exists in the kernel, but used only in a limited scope. It's only used in -CURRENT. It would be a really big step forward, if we were enable them for -STABLE branches too, because these beaches changes significantly too without enabled KASSERT. > > But in userland our asserts come from , and that is a > problem. > > The main trouble with using assert(3) is that random people > illadvisedly set NDEBUG expecting their code to run faster as a > result. > > It does not. > > Almost all the asserts in Varnish happens on values already in CPU > registers and/or cache and I have never been able to credibly measure > a performance impact from the asserts in Varnish. > > Besides, many of the asserts never make it to the CPU, modern > compilers have strong analysis which can see that the can never > trigger, so they are removed in optimization. > > We cannot change to get rid of the NDEBUG mistake, and > in a more abstract line of thought we probably should not even use > for FreeBSD source code - it sort of belongs to the users. > > I suggest and strongly urge that we add a set of userland assert-macros > which are never compiled out, for use *only* in FreeBSD userland > source code, and that we sprinkle them liberally, in particular > anything setuid etc. > > In Varnish Cache we have four "kinds" of asserts, which allows us > to communicate crucial information in the message to the users. I > don't know if a similar subdivision of asserts would make sense for > FreeBSD, but I mention it here as inspiration: > > 1. "Regular asserts" - things which are just plain wrong, which > probably means we have a genuine bug somewhere. Examples could > be null pointers where previous checks should have ensured this > not be so. Also error situations for which there is no saner > handling that killing the projcess. > > 2. "xxx asserts" - situations which should (almost) never happen, > and for which we could do more productive error handling, but > where the seldomness of the condition makes it a bad idea (ie: > untested code) and a bad investment of our developer time to do > so. Disk full is a good example for Varnish. > > 3. "wrong asserts" - Internal state is messed up, program flow > has taken a "impossible" branch. A good example is the > default branch of a switch on a finite input set. > > 4. "Incomplete asserts" - Code we have not written yet, extension > points not open for business yet, very strange corner-cases > belived to be impossible, but not proven to be so yet. > > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >