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 X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46767C4338F for ; Wed, 18 Aug 2021 06:16:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CD1A960F35 for ; Wed, 18 Aug 2021 06:16:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CD1A960F35 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 687DB8D0001; Wed, 18 Aug 2021 02:16:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6386E6B0072; Wed, 18 Aug 2021 02:16:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FF4C8D0001; Wed, 18 Aug 2021 02:16:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0164.hostedemail.com [216.40.44.164]) by kanga.kvack.org (Postfix) with ESMTP id 347496B006C for ; Wed, 18 Aug 2021 02:16:50 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C56D6182405DC for ; Wed, 18 Aug 2021 06:16:49 +0000 (UTC) X-FDA: 78487192938.22.E662B58 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf03.hostedemail.com (Postfix) with ESMTP id 72276300E03E for ; Wed, 18 Aug 2021 06:16:49 +0000 (UTC) Received: by mail-pf1-f172.google.com with SMTP id x16so1088513pfh.2 for ; Tue, 17 Aug 2021 23:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=qiIiGr/kHO0o1yd85XRx1S/oZrG0a2JVuYsGSPTdPKo=; b=TVddYFx6MZtUu6Gxm5/eq0JnenoYTy2o0WAaLORc6h1rDy3BlAe2MfSQ47sEsZq8aI rnkdVNPYX5ygc3HUGUQrRXKtNe8UxzUZbp49tIfPnQpFN+mMiPemA6Att138bqInZkIs KMMMUh77ITc3FJ3DEFh+jNbzkZpixYigdra/M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=qiIiGr/kHO0o1yd85XRx1S/oZrG0a2JVuYsGSPTdPKo=; b=FJZN7qsIh9ppXTyCAArdPrGwldf/oLBwcMvgN/WMine0Cvk/fDfkcoD/EkdsUEjxbE 4wjNd4uXhhE9fXagk+X7qfYczN5h+8C6Lqp6aX22WhWGNntyBtc9Lc7QJp+ZuATCtgri YKfOcSTUtBJ9ieL23g1sfBwGXS1lUzy1dQHMMzOX8MqFcPNS1OKI4Z7a9CNlx3+sk6rm 19v/ScShdLXg9IhVruvMDIlyv3hp5gFnYpPaKAaTMTsap2PZBzB9ujnCVZVkmro8wbzK sHBeA6FQzDJJZgv9yua1JiUWRQOlHnrtkbbVWyJnMbY+iYvdv6Or7BqmCNw7pzxEcOvQ CfHg== X-Gm-Message-State: AOAM531LWmRe5fdNmzWVMoZIb4K40YuZ0isbWPEnJX3Zd3+UIjUuukae BS6w+ejzvYoztfDyoMRi8qn3MA== X-Google-Smtp-Source: ABdhPJzejJTLjdMfXxVAJFIQjmpX7APIS6kpuwCjVMxxOkuNDs4SSrs+ZQmfcYcc43+NKU1r5qPLjQ== X-Received: by 2002:a63:5fcc:: with SMTP id t195mr7237993pgb.146.1629267408588; Tue, 17 Aug 2021 23:16:48 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id l11sm4943382pfd.187.2021.08.17.23.16.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Aug 2021 23:16:48 -0700 (PDT) Date: Tue, 17 Aug 2021 23:16:47 -0700 From: Kees Cook To: Joe Perches Cc: linux-kernel@vger.kernel.org, Daniel Micay , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , linux-mm@kvack.org, Miguel Ojeda , Nathan Chancellor , Nick Desaulniers , Dennis Zhou , Tejun Heo , Masahiro Yamada , Michal Marek , clang-built-linux@googlegroups.com, linux-kbuild@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH 2/5] slab: Add __alloc_size attributes for better bounds checking Message-ID: <202108172312.7032A3E@keescook> References: <20210818050841.2226600-1-keescook@chromium.org> <20210818050841.2226600-3-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 72276300E03E Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=TVddYFx6; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf03.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.172 as permitted sender) smtp.mailfrom=keescook@chromium.org X-Rspamd-Server: rspam04 X-Stat-Signature: a779ex4dyibraugebsdgd1s8o47jy8yg X-HE-Tag: 1629267409-351822 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Aug 17, 2021 at 10:31:32PM -0700, Joe Perches wrote: > On Tue, 2021-08-17 at 22:08 -0700, Kees Cook wrote: > > As already done in GrapheneOS, add the __alloc_size attribute for > > regular kmalloc interfaces, to provide additional hinting for better > > bounds checking, assisting CONFIG_FORTIFY_SOURCE and other compiler > > optimizations. > [] > > diff --git a/include/linux/slab.h b/include/linux/slab.h > [] > > @@ -181,7 +181,7 @@ int kmem_cache_shrink(struct kmem_cache *); > > =A0/* > > =A0=A0* Common kmalloc functions provided by all allocators > > =A0=A0*/ > > -void * __must_check krealloc(const void *, size_t, gfp_t); > > +void * __must_check krealloc(const void *, size_t, gfp_t) __alloc_si= ze(2); >=20 > I suggest the __alloc_size attribute be placed at the beginning of the > function declaration to be more similar to the common __printf attribut= e > location uses. Yeah, any consistent ordering suggestions are welcome here; thank you! These declarations were all over the place, and trying to follow each slightly different existing style made my eyes hurt. :) > __alloc_size(2) > void * __must_check krealloc(const void *, size_t, gfp_t); >=20 > I really prefer the __must_check to be with the other attribute and tha= t > function declarations have argument names too like: >=20 > __alloc_size(2) __must_check > void *krealloc(const void *ptr, size_t size, gfp_t gfp); I'm happy with whatever makes the most sense. > but there are a _lot_ of placement of __must_check after the return typ= e >=20 > Lastly __alloc_size should probably be added to checkpatch Oh, yes! Thanks for the reminder. > Maybe: > --- > scripts/checkpatch.pl | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl > index 161ce7fe5d1e5..1a166b5cf3447 100755 > --- a/scripts/checkpatch.pl > +++ b/scripts/checkpatch.pl > @@ -489,7 +489,8 @@ our $Attribute =3D qr{ > ____cacheline_aligned| > ____cacheline_aligned_in_smp| > ____cacheline_internodealigned_in_smp| > - __weak > + __weak| > + __alloc_size\s*\(\s*\d+\s*(?:,\s*d+\s*){0,5}\) Why the "{0,5}" bit here? I was expecting just "?". (i.e. it can have either 1 or 2 arguments.) > }x; > our $Modifier; > our $Inline =3D qr{inline|__always_inline|noinline|__inline|__inline__= }; >=20 >=20 --=20 Kees Cook