Received: by 10.192.165.148 with SMTP id m20csp220187imm; Wed, 9 May 2018 11:27:57 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoDzbdqeA8FgolfnhLxd62XauZLiDZBQunjqTlxzhlFeq3pl6DBczVUVdLk2vB/Au1uwzTl X-Received: by 2002:a65:4542:: with SMTP id x2-v6mr37588472pgr.24.1525890477525; Wed, 09 May 2018 11:27:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525890477; cv=none; d=google.com; s=arc-20160816; b=lp0HKZG0EoVOlILqjkJDIjQIF3xwzPKNlPckfL+k6ktQvoDZNXG1sHpEcxDa+AQ2gf iU3Tuf9QnVHefhEBNCw+OB48lzprVUZBtKZUV0YZp4fd3aCwEJvGilNoIM35aCQdGPLC Mf3xNXwOlGXaRFP4e7e0yJxclqrG4N09ITmOMhTbZvlj5vNv/DAr4vXq/UqeWzTHQfAg qLzvOli5SrdcO3dRcSkuYiJ0r5+B2L8DWtKRvSAAT0FfjaxW4CQ5DWfWqigf/vitJe8l 4HvK+IqhRaqnbwRR8ElUYEHG25fv+QnfCVatRxlR61V8sCo1i2J1WInXKQR0EwNO8jZ4 DRUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=8aFgZumqHWFKVbRSGVfkaeNB0cyycTjWBLlm3T0VZTA=; b=Q8SGvZlTtrfTu2MsKCeGo1AqF9wFTnp3R0jsLqAOwuxyFJun5ANmFhXHud15wpiMQh 98aMlVrH0emYky7t3wnrFkc13/mJPzueEOtcq7pRdoAmXZtleooX5oqiWoFRt0IgQK92 H+XjAtDikXKWwLY3ZooRM6D3foq19lUZNqn/vpiz+PPqdWU3jWUS3Lzs1KeFiBspfcDR iUkZMWL4Q4RGIF2g5Zfl5wcavMC1lIr0h5FwVW5k59qHrFuxy8sxFgqRWAOgcZl0Bdwc rsR2ya2C8k3oE19bTapbTASZWhmYMz4R87OoTsolMlDwSiYKFjUj5+vLJ8jRRnxNX18v Xcuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=NH4dShXx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y9-v6si18978692pgc.601.2018.05.09.11.27.42; Wed, 09 May 2018 11:27:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=NH4dShXx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964796AbeEIS11 (ORCPT + 99 others); Wed, 9 May 2018 14:27:27 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:39740 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933577AbeEIS10 (ORCPT ); Wed, 9 May 2018 14:27:26 -0400 Received: by mail-wm0-f65.google.com with SMTP id f8-v6so67983wmc.4 for ; Wed, 09 May 2018 11:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8aFgZumqHWFKVbRSGVfkaeNB0cyycTjWBLlm3T0VZTA=; b=NH4dShXxcmxD+yIihsvdhp+4xtBJ3mzgIr+hseAq5WxbgcIs/sLxz3OicXHI6i6Ye+ lcIyFUvXdIpaHrYK1rX8SJWqZdBvoHXoSoI7E0JvE65W7bn47CAVNvBBI8BDGQgUFeri eiOyr15MX9cJOlKANBYG/M4gnwxkiLFGSpAck= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8aFgZumqHWFKVbRSGVfkaeNB0cyycTjWBLlm3T0VZTA=; b=rrrvnrRi0uqpis5ypLhXGMNeC1fd4bC1U2/QWQ741BkFmAkTudrinZUzBgFDoaFiRS Pye6M4nhR+Zlq7liNMVb1lZm099w0XjjI0vL4nSEs4hcJhF/rZbXbSqrPeGu/vDtHcZF 2Oh0OGZyuD5KTr/e6OB8Sa0e90btU3hd9nrnj0X9PbTJVdEEJcdOWUMjZTIIIRCPYCBV uRJVylgQP+mn4x1obOW++C0265seCUaFvr+KUzBhdwpoO60rYjwEhWhyKvgjlk0rT6zo kAan/GKfQ9RwtZe4uVV/5V0zB6wilpTQ6y4dEJffd2Yrdo8UcH3bj3H6hxRqBoJtwhv0 KLqg== X-Gm-Message-State: ALQs6tDPAnO+H4+60vouLjuc9Rtn3+2rSCE/tjNzWz2OSUK9GXQX3Mvg JbxjLDJ4u1wjy4UbkIUvCksKdBPCnB8= X-Received: by 2002:a50:921c:: with SMTP id i28-v6mr60827278eda.27.1525890444882; Wed, 09 May 2018 11:27:24 -0700 (PDT) Received: from [192.168.0.189] (dhcp-5-186-126-104.cgn.ip.fibianet.dk. [5.186.126.104]) by smtp.gmail.com with ESMTPSA id b43-v6sm16895021edc.34.2018.05.09.11.27.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 11:27:24 -0700 (PDT) Subject: Re: [PATCH 03/13] overflow.h: Add allocation size calculation helpers To: Kees Cook , Matthew Wilcox Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-hardening@lists.openwall.com References: <20180509004229.36341-1-keescook@chromium.org> <20180509004229.36341-4-keescook@chromium.org> From: Rasmus Villemoes Message-ID: Date: Wed, 9 May 2018 20:27:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180509004229.36341-4-keescook@chromium.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-05-09 02:42, Kees Cook wrote: > In preparation for replacing unchecked overflows for memory allocations, > this creates helpers for the 3 most common calculations: > > array_size(a, b): 2-dimensional array > array3_size(a, b, c): 2-dimensional array yeah... complete confusion... > +/** > + * array_size() - Calculate size of 2-dimensional array. > + * > + * @a: dimension one > + * @b: dimension two > + * > + * Calculates size of 2-dimensional array: @a * @b. > + * > + * Returns: number of bytes needed to represent the array or SIZE_MAX on > + * overflow. > + */ > +static inline __must_check size_t array_size(size_t a, size_t b) > +{ > + size_t bytes; > + > + if (check_mul_overflow(a, b, &bytes)) > + return SIZE_MAX; > + > + return bytes; > +} > + > +/** > + * array3_size() - Calculate size of 3-dimensional array. > + * ...IDGI. array_size is/will most often be used to calculate the size of a one-dimensional array, count*elemsize, accessed as foo[i]. Won't a three-factor product usually be dim1*dim2*elemsize, i.e. 2-dimensional, accessed (because C is lame) as foo[i*dim2 + j]? > +/** > + * struct_size() - Calculate size of structure with trailing array. > + * @p: Pointer to the structure. > + * @member: Name of the array member. > + * @n: Number of elements in the array. > + * > + * Calculates size of memory needed for structure @p followed by an > + * array of @n @member elements. > + * > + * Return: number of bytes needed or SIZE_MAX on overflow. > + */ > +#define struct_size(p, member, n) \ > + __ab_c_size(n, \ > + sizeof(*(p)->member) + __must_be_array((p)->member),\ > + offsetof(typeof(*(p)), member)) > + > + struct s { int a; char b; char c[]; } has sizeof > offsetof(c), so for small enough n, we end up allocating less than sizeof(struct s). And the caller might reasonably do memset(s, 0, sizeof(*s)) to initialize all members before c. In practice our allocators round up to a multiple of 8, so I don't think it's a big problem, but some sanitizer might complain. But I do think you should make that addend sizeof() instead of offsetof(). Rasmus