From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5139 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.lib.musl.general Subject: Re: thoughts on reallocarray, explicit_bzero? Date: Mon, 19 May 2014 15:08:11 -0700 Message-ID: <537A80CB.3040308@mit.edu> References: <20140519153130.GA519@muslin> <20140519162556.GY12324@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1400537313 23118 80.91.229.3 (19 May 2014 22:08:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 May 2014 22:08:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5144-gllmg-musl=m.gmane.org@lists.openwall.com Tue May 20 00:08:28 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WmVjP-0006Z3-Uc for gllmg-musl@plane.gmane.org; Tue, 20 May 2014 00:08:28 +0200 Original-Received: (qmail 17570 invoked by uid 550); 19 May 2014 22:08:27 -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 17562 invoked from network); 19 May 2014 22:08:26 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PDeAiNU0nFAYGX2qi5K0zYhoxrq3MphXROyhyBj6ROk=; b=V+ImCPqdzKxg9f+r6lJgfRPSN7kHuVac9S7DI7YSnkRHfdho1izyxIceb2wz6XzYgx esMBhyEC5PMfVLqdNTCXdeGnkIJi5jBUZyIfJW0fdadEjCNM8s6+RocwE6y6bFVSb3Zd LZl1eFZxI75lndKb6JAI5i++X126SdUAIeBIUrGCihNLDiWcangbDlxZHf6Tbkfp+AY+ Mryppv8RQiMqFoAPag9RXv3Y/LEuZXTE3fsAgHp3p4uyxqHg4ss9/NQuW0CaFbCmc51o 7aAF6y53TfjZmSugXWvW/GDJixT482ffkxPJRHe795/+3lXJG7Vkud36lPCHMMC9dLYQ joRw== X-Gm-Message-State: ALoCoQlVU5cUhynF/gR8uDMiA5NMMSA4/Rt6YQDqf1XKgqiLfc/F90E9HnCfL82dxgS5OLaD430R X-Received: by 10.66.146.170 with SMTP id td10mr46384857pab.105.1400537293562; Mon, 19 May 2014 15:08:13 -0700 (PDT) X-Google-Original-From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <20140519162556.GY12324@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:5139 Archived-At: On 05/19/2014 09:25 AM, Szabolcs Nagy wrote: > * Isaac Dunham [2014-05-19 08:31:31 -0700]: >> Having read up on the LibreSSL fork of OpenSSL and also recently >> backported a nuber of libXfont CVE fixes for integer overflows, >> I've seen the risk posed by malloc(n*sizeof(x)) and realloc(ptr, >> n*sizeof(x)). >> calloc(n, sizeof(x)) can be used in place of malloc(n * sizeof(x)), >> but there's no standard function that does overflow checking for >> realloc(). OpenBSD has provided the extension reallocarray(), which >> provides for bounds checking like calloc() does. > > i'd use a saturated multiplication, because malloc/realloc > are not the only places where overflowing size calculations > may cause problems and in such cases (size_t)-1 is just as > good as a failure and it can be added to your code without > portability issues > > static size_t sizemul(size_t a, size_t b) > { > return b>1 && a>1 && a>-1/b ? -1 : a*b; > } Before going nuts trying to optimize this, it may pay to write some good-enough helper and to use native compiler support for this, which is already available in Clang [1] and should be coming reasonably soon in gcc [2]. I suspect that, on all reasonably platforms, if doublesize_t is the unsigned type that's twice as wide as size_t, then this isn't too bad either: doublesize_t total = (doublesize_t)a * (doublesize_t)b; if (total > SIZE_MAX) fail; For quite a while, gcc has had a 128-bit integer type that works on 64-bit platforms, and gcc should always support a 64-bit type on 32-bit platforms. On systems with widening multiply (e.g. x86), even if the optimizer doesn't detect the idiom, this is only a few cycles slower than the optimal code. [1] http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61129 --Andy