From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5CF08C47DD9 for ; Wed, 28 Feb 2024 21:37:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IuQYeRxktgmT5472OP1U7MHeY/BdsHUxKzLBR7a7zEQ=; b=r48SvrMUPRff5I DRy3CR/iUlUOwFdaRsZsN/V1LJ8Pc1UP6IlOyGuYBdJWscQtH1Ru06ajyl4AQFFcyjPnWTLuc1LNY x59lH0Fp29Aap69IOX6vW29iPfgZKOvlDirlV7cEsvVXx4XW92MieJegNtt3bgPl/AVTIt297wqWf hMkRZAdXRtJHI/tEwGAfRq3Teyz7fRQBNLX79gLnDmPF1OQtlgscTCteSf+IQe8pzLekImKRT/TMk u16PrC+ELBPl+pxqOi72G3bkJQsmcF4F650t9TwV/aE7GHRshHGJL0AjSNX3J9o0Awa7Tgyc8E2Fc mal6BfXoSdTQxDFXKWAQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfRcT-0000000B0vg-38PQ; Wed, 28 Feb 2024 21:37:41 +0000 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfRcQ-0000000B0uv-3chC for linux-arm-kernel@lists.infradead.org; Wed, 28 Feb 2024 21:37:40 +0000 Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1dc09556599so2569805ad.1 for ; Wed, 28 Feb 2024 13:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709156258; x=1709761058; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mxMa3ysfVhpuWlSkP2rUbxFtq6lVsWzk+l7tYIpoG5M=; b=DVT9vjq0BBPs8RrRWtiEnRfGweNXzV+FaxidZlYKV0m23wWS0vhiKDeYzoKd/WMBQs Fo94abPm+IWGLVpSbJi4PAErKz/egOiBRc308iG9STybgcEsvcGAZyyqGYawevZvvhs1 ziz8oghhymU0gtvvYJLvGdjnyh/QRCiKC4m7A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709156258; x=1709761058; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mxMa3ysfVhpuWlSkP2rUbxFtq6lVsWzk+l7tYIpoG5M=; b=o8stjVU1ZxQzJxaF3olXG5lMYaBzivvMatB3yYSImOVGxsjVWslK7gInPl3B+WHwSq HlDbjpRKXgWDQIwJR8Sx7FnnSTDkzeh+tt/T+I47QMwq1jSMN4bsc0oLtrV67Gyb3H6H CAr2HZt8SIWRJuXc5PLyxXGkQElGcvbWRkTkrJPOGKZc+79czKL7iriGzD6Y/mG4RB/R LRcoKs+tA64T39vUL661mr816x2eNYtjbvmAsRod3miXZ0jhdiNXVLGYzxFMv9zj46hg oquiIaZyNS9F3NiReispY4Q586bhfh4yGehGhrnpTmT7pIrJPfhjQIJIfEx8gfs/dpqJ b0kQ== X-Forwarded-Encrypted: i=1; AJvYcCWDNcen6BccoD+x0Zg0YWBNojbsUGJV6dWTUDl6PeWCkv0xtQmPkZWqrZ4Ot75jvLM3sVpaFQCmsK46S4yTUg08J250uIwMdF1ZbxFNZzBO4xLBkN4= X-Gm-Message-State: AOJu0Yxh86ubekNRiu4sHkjgGW/D+r5zRyzfMgSq230ievgnPNCJU7Sx Qw4TmFhdKb7mHtAMw/EPTdlIWNRnFfYmbIgd2L93wyPF9t+LXqMK9dYPbb/MRw== X-Google-Smtp-Source: AGHT+IEutCCddWBfZZf+Zq/1ILDM/Qx+dYsp5vYX2jxxagWboMTFdshkkBQuR0Dtvr+YU4cuJ4wNtA== X-Received: by 2002:a17:902:8d8a:b0:1db:e7a7:63f4 with SMTP id v10-20020a1709028d8a00b001dbe7a763f4mr163725plo.19.1709156257805; Wed, 28 Feb 2024 13:37:37 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id r20-20020a170903411400b001d8f111804asm3781604pld.113.2024.02.28.13.37.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Feb 2024 13:37:36 -0800 (PST) Date: Wed, 28 Feb 2024 13:37:36 -0800 From: Kees Cook To: Andy Shevchenko Cc: Vinod Koul , Linus Walleij , Jonathan Cameron , Mark Brown , linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, linux-spi@vger.kernel.org, netdev@vger.kernel.org, linux-hardening@vger.kernel.org, Jonathan Cameron , Lars-Peter Clausen , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , "Gustavo A. R. Silva" Subject: Re: [PATCH v4 2/8] overflow: Add struct_size_with_data() and struct_data_pointer() helpers Message-ID: <202402281334.876DC89@keescook> References: <20240228204919.3680786-1-andriy.shevchenko@linux.intel.com> <20240228204919.3680786-3-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240228204919.3680786-3-andriy.shevchenko@linux.intel.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240228_133738_943995_4063249C X-CRM114-Status: GOOD ( 23.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Feb 28, 2024 at 10:41:32PM +0200, Andy Shevchenko wrote: > Introduce two helper macros to calculate the size of the structure > with trailing aligned data and to retrieve the pointer to that data. > > Signed-off-by: Andy Shevchenko > --- > include/linux/overflow.h | 27 ++++++++++++++++++++++++++- > 1 file changed, 26 insertions(+), 1 deletion(-) > > diff --git a/include/linux/overflow.h b/include/linux/overflow.h > index bc390f026128..b93bbf1b6aaa 100644 > --- a/include/linux/overflow.h > +++ b/include/linux/overflow.h > @@ -2,9 +2,10 @@ > #ifndef __LINUX_OVERFLOW_H > #define __LINUX_OVERFLOW_H > > +#include > #include > -#include > #include > +#include > > /* > * We need to compute the minimum and maximum values representable in a given > @@ -337,6 +338,30 @@ static inline size_t __must_check size_sub(size_t minuend, size_t subtrahend) > */ > #define array3_size(a, b, c) size_mul(size_mul(a, b), c) > > +/** > + * struct_size_with_data() - Calculate size of structure with trailing aligned data. > + * @p: Pointer to the structure. > + * @a: Alignment in bytes before trailing data. > + * @s: Data size in bytes (must not be 0). > + * > + * Calculates size of memory needed for structure of @p followed by an > + * aligned data of size @s. > + * > + * Return: number of bytes needed or SIZE_MAX on overflow. > + */ > +#define struct_size_with_data(p, a, s) size_add(ALIGN(sizeof(*(p)), (a)), (s)) I don't like this -- "p" should have a trailing flexible array. (See below.) > + > +/** > + * struct_data_pointer - Calculate offset of the trailing data reserved with > + * struct_size_with_data(). > + * @p: Pointer to the structure. > + * @a: Alignment in bytes before trailing data. > + * > + * Return: offset in bytes to the trailing data reserved with > + * struct_size_with_data(). > + */ > +#define struct_data_pointer(p, a) PTR_ALIGN((void *)((p) + 1), (a)) I'm not super excited about propagating the "p + 1" code pattern to find things after an allocation. This leads to the compiler either being blind to accesses beyond an allocation, or being too conservative about accesses beyond an object. Instead of these helpers I would much prefer that data structures that use this code pattern be converted to using trailing flexible arrays, at which point the compiler is in a much better position to reason about sizes. -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel