Message ID | 20221018073430.never.551-kees@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp1823990wrs; Tue, 18 Oct 2022 00:39:02 -0700 (PDT) X-Google-Smtp-Source: AMsMyM53X/XQ9qb59KCJ5nGaYT9NriJeUOzg0fF0llLqv0Pya1wDJS5kUcp5WbBqr8RXTW0slQIy X-Received: by 2002:a17:906:eec7:b0:733:189f:b07a with SMTP id wu7-20020a170906eec700b00733189fb07amr1334651ejb.230.1666078741872; Tue, 18 Oct 2022 00:39:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666078741; cv=none; d=google.com; s=arc-20160816; b=vPW+M9ZBmCPoUKy74sxSPr/JXRp2wdkY3LJvDiIsISdyjenoLJsVlRusiq5aAJCthe rNR0ZT7WcQCW03nXx2pnqwErq1pbDlqTEwhaMktwTXqTg5hA2T/xONIvKAxd+8Fa1Hm+ 220D9oLtBkDwIjAi0uwYAPnluR7DVFnJH0dgb0lJwzTqWJsBFOc70gC/Kyo/PlB/wk/B bWAdC+5GvXzxHlJBi8PkuMljr87fJIxRJ03ZctKKPRpRbFJkHnlhgrkPkzeHz+r8FhUP lmmPJt4e1OcSXGM5NxeBl/i3yRSTSUMHqcKWweew6TciggZUGb+Fj0XQorhH6rVR07hL 4i8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=LlsuHZmleDlGS7hXnmTuG4KQrPThOgrPcWg+CPNzZ2Y=; b=npsEg8S7aKhTVznvQ33l0qYc9FHl0b+OJClbQ+F8O0yrG5nh7t8rHRXbjSHG5ERQvg spd37b7XWxkuw3V0DYT2cXhzAV8qeECGE3+OCWTrnLtJ1RZ83UOWmh6t3VbbgM+m3uB1 AohZ51vLiGi5dtLuWLz/KwrKU13JwVC4CxETPJG4J94ePgFHLDFW0J0Q07c/d8gsHoZd uepxiquhkP4pbcFY5/6/6CgkDKO/7vHuSMKRlfR8AdOq/dWlz4zYuq8L+s+jdfuyiiNV lVwCqdMV56V2zyVThP9bOoPvDstwDJDcS8gq08BEdsK8hmFeOUGcCg4/l2+Lme5sbqQB +tvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=lbc5UKDb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o10-20020aa7dd4a000000b0045c42a9f588si10210897edw.408.2022.10.18.00.38.37; Tue, 18 Oct 2022 00:39:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=lbc5UKDb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230121AbiJRHe6 (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Tue, 18 Oct 2022 03:34:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230303AbiJRHex (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 18 Oct 2022 03:34:53 -0400 Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93813220C1 for <linux-kernel@vger.kernel.org>; Tue, 18 Oct 2022 00:34:51 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id f140so13329742pfa.1 for <linux-kernel@vger.kernel.org>; Tue, 18 Oct 2022 00:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=LlsuHZmleDlGS7hXnmTuG4KQrPThOgrPcWg+CPNzZ2Y=; b=lbc5UKDbqNoCtYKP519m1+Nh5+thrYMQcy0LlJI8WQVPOOebBqFmQNzsq92hnwGkzn 3PVd6AetOnLncoxE4j0FqlexwwNWGZLQj+FUIopGxBZeb8O7t7RXlORIhxxP6rjDxd6P VNi2rPCGtNrRgaRJ9balyeEtPKBM0VeQKnexM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LlsuHZmleDlGS7hXnmTuG4KQrPThOgrPcWg+CPNzZ2Y=; b=fQCL1TRo3O33iRLJf+hyrqS+rXRH74qevTe6vgbF5+XKDVwflifKEffPxzH5rc2U7A qWgdTpxq9lGuU+s4NDe56WGLu3Nz7kMCT6rCXr+E7zYDB9gWVz/CJUnPGCb5ysvnIpx8 gENuQArrT9T2aY2PD91GODJXbqUT5lVsrNX4bDAstV8cC/qYL7ugJ+TJeANSNMzUltFM nQWfII32McHVdaMiL4u7WeYbZwcyQjgnGNI/L7P6Wmcqg9NMLgJwpIOUvbu3EjfeqFvf T1dTgCuK36LDOgaU+l5kX0lrUFq8m+dQcqli7+LJ9eq3GvOkRdBxjg4SuWAMDhCncUXf frkA== X-Gm-Message-State: ACrzQf1iXoqyGbdKWdDUjOLiTVrxO9GUX7ia9wqLgPf1k4FhJqkLywFZ cgl+VInLp54BiPhSFAw52EwjgQ== X-Received: by 2002:a63:2221:0:b0:43b:f4a3:80cc with SMTP id i33-20020a632221000000b0043bf4a380ccmr1543022pgi.367.1666078491096; Tue, 18 Oct 2022 00:34:51 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id o63-20020a62cd42000000b0056258a3606csm8378759pfg.215.2022.10.18.00.34.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 00:34:50 -0700 (PDT) From: Kees Cook <keescook@chromium.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Kees Cook <keescook@chromium.org>, Thomas Gleixner <tglx@linutronix.de>, Jason Gunthorpe <jgg@ziepe.ca>, Nishanth Menon <nm@ti.com>, Michael Kelley <mikelley@microsoft.com>, Dan Williams <dan.j.williams@intel.com>, Won Chung <wonchung@google.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH] driver core: Add __alloc_size hint to devm allocators Date: Tue, 18 Oct 2022 00:34:47 -0700 Message-Id: <20221018073430.never.551-kees@kernel.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2035; h=from:subject:message-id; bh=bz9s+ekJyLE4FWcnomuQSloLzhEk4e+5O8t5nTvLkPw=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBjTlcWPmKRYJExrJMYBfXkIFPZXjLaDn+MpfMNiKR0 Y3SacTyJAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCY05XFgAKCRCJcvTf3G3AJk2HD/ 91RjYQfqDb06XAma88pJqfLxntl+ZmLIK6HoEa9cpfJlpOb0VrM2NUsth9NuPqSYxrE43QWZ+oATUG yBItJ7YVQPmJHbWjdn/S04rMjB1lcbjft1TPm4HGV7eMXPfWIR6mTgv4cNEUrfGn5f30hgT7BFUMvg OEQtVKyRigOonq/AaAZqIkAPfctm1mTr3LBpmBraQKrezwe6qQRRizPCHAQRY7msd0EO9KSn9q8+s9 TFh1a4n7Zwa06deQ2wVZaD53WXpc9er+c5HNplcin9+NJFz2pMCc79aNkRIFvs09jGnllzdtQ3zX+K MW53U0n3s/4mr2/HSYOor1f2TkA0ysz+dpj69VzeoRkKJnVXNZ8BDzXbmKFvndsao0AA+Y0CfZoBw7 04KoMRC/b9tzyBJW7lfmM46WXaPgsMGXBLlMH9NHBazXIepofyWFd4uJAZwNDBJcerVU1LhMjdGNKB vzKH31svHifUgUStFk08b0gALDpawNjMq2NdyqO9DL1upbWU+HM8P/djAwVifovATK6I7Q65R3mcli lz+qKxw4rPIH7HrpgAYapQ31rRZCHhdiqyg7U8LES8ZSU8jtUau1L7bI4a95w8+sN6Aq7NMkWleB2W jL2jOaI3BbLbea62IROIE8Ox5s4FKOG4jBbsLw1ppYTGb8QOCWO72DCnXHLA== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747010182702726197?= X-GMAIL-MSGID: =?utf-8?q?1747010182702726197?= |
Series |
driver core: Add __alloc_size hint to devm allocators
|
|
Commit Message
Kees Cook
Oct. 18, 2022, 7:34 a.m. UTC
Mark the devm_*alloc()-family of allocations with appropriate
__alloc_size() hints so the compiler can attempt to reason about buffer
lengths from allocations.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nishanth Menon <nm@ti.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Won Chung <wonchung@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
include/linux/device.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Comments
On 18/10/2022 09.34, Kees Cook wrote: > Mark the devm_*alloc()-family of allocations with appropriate > __alloc_size() hints so the compiler can attempt to reason about buffer > lengths from allocations. > > @@ -226,7 +226,8 @@ static inline void *devm_kcalloc(struct device *dev, > void devm_kfree(struct device *dev, const void *p); > char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp) __malloc; > const char *devm_kstrdup_const(struct device *dev, const char *s, gfp_t gfp); > -void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp); > +void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp) > + __alloc_size(3); I think it's wrong to apply the __malloc attribute to kmemdup() and variants. 'malloc' This tells the compiler that a function is 'malloc'-like, i.e., that the pointer P returned by the function cannot alias any other pointer valid when the function returns, and moreover no pointers to valid objects occur in any storage addressed by P. See also commit d64e85d3e1c5, introducing __malloc in the first place. Maybe worth lifting some of that to a comment somewhere. Rasmus
On Tue, Oct 18, 2022 at 12:09:30PM +0200, Rasmus Villemoes wrote: > On 18/10/2022 09.34, Kees Cook wrote: > > Mark the devm_*alloc()-family of allocations with appropriate > > __alloc_size() hints so the compiler can attempt to reason about buffer > > lengths from allocations. > > > > > @@ -226,7 +226,8 @@ static inline void *devm_kcalloc(struct device *dev, > > void devm_kfree(struct device *dev, const void *p); > > char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp) __malloc; > > const char *devm_kstrdup_const(struct device *dev, const char *s, gfp_t gfp); > > -void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp); > > +void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp) > > + __alloc_size(3); > > I think it's wrong to apply the __malloc attribute to kmemdup() and > variants. > > 'malloc' > This tells the compiler that a function is 'malloc'-like, i.e., > that the pointer P returned by the function cannot alias any other > pointer valid when the function returns, and moreover no pointers > to valid objects occur in any storage addressed by P. Oh, ew, it defines rules about _contents_ as well. Thank you for pointing that out! I suppose we can use __realloc_size for these cases then?
On 18/10/2022 12.15, Kees Cook wrote: > On Tue, Oct 18, 2022 at 12:09:30PM +0200, Rasmus Villemoes wrote: >> On 18/10/2022 09.34, Kees Cook wrote: >>> Mark the devm_*alloc()-family of allocations with appropriate >>> __alloc_size() hints so the compiler can attempt to reason about buffer >>> lengths from allocations. >>> >> >>> @@ -226,7 +226,8 @@ static inline void *devm_kcalloc(struct device *dev, >>> void devm_kfree(struct device *dev, const void *p); >>> char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp) __malloc; >>> const char *devm_kstrdup_const(struct device *dev, const char *s, gfp_t gfp); >>> -void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp); >>> +void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp) >>> + __alloc_size(3); >> >> I think it's wrong to apply the __malloc attribute to kmemdup() and >> variants. >> >> 'malloc' >> This tells the compiler that a function is 'malloc'-like, i.e., >> that the pointer P returned by the function cannot alias any other >> pointer valid when the function returns, and moreover no pointers >> to valid objects occur in any storage addressed by P. > > Oh, ew, it defines rules about _contents_ as well. Thank you for > pointing that out! > > I suppose we can use __realloc_size for these cases then? Probably, but it's gonna be mighty confusing for people reading the code. I was never really a fan of including __malloc in __alloc_size in the first place, this is the kind of confusion that comes from having one attribute include another without having the developer forced to think about whether both actually apply in a given situation. And that malloc documentation (both the old and the fixed) even came up in what I assume is the thread that led up to that Since anything marked with __alloc_size would also qualify for marking with __malloc, just include __malloc along with it to avoid redundant markings. (Suggested by Linus Torvalds.) in commit 86cffecd, namely https://lore.kernel.org/mm-commits/202109101138.53FCADF5C@keescook/ . Rasmus
diff --git a/include/linux/device.h b/include/linux/device.h index 424b55df0272..a1cbbab9a57a 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -197,9 +197,9 @@ void devres_remove_group(struct device *dev, void *id); int devres_release_group(struct device *dev, void *id); /* managed devm_k.alloc/kfree for device drivers */ -void *devm_kmalloc(struct device *dev, size_t size, gfp_t gfp) __malloc; +void *devm_kmalloc(struct device *dev, size_t size, gfp_t gfp) __alloc_size(2); void *devm_krealloc(struct device *dev, void *ptr, size_t size, - gfp_t gfp) __must_check; + gfp_t gfp) __must_check __realloc_size(3); __printf(3, 0) char *devm_kvasprintf(struct device *dev, gfp_t gfp, const char *fmt, va_list ap) __malloc; __printf(3, 4) char *devm_kasprintf(struct device *dev, gfp_t gfp, @@ -226,7 +226,8 @@ static inline void *devm_kcalloc(struct device *dev, void devm_kfree(struct device *dev, const void *p); char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp) __malloc; const char *devm_kstrdup_const(struct device *dev, const char *s, gfp_t gfp); -void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp); +void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp) + __alloc_size(3); unsigned long devm_get_free_pages(struct device *dev, gfp_t gfp_mask, unsigned int order);