Message ID | 20221018092526.4035344-2-keescook@chromium.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 y7csp1858484wrs; Tue, 18 Oct 2022 02:29:14 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6Y03Vies9EeJ6KKHd+C6lbhyhrZpu+okIvb4zpTDXfSuynOWddMPurAmQu68j3ZreY+5H3 X-Received: by 2002:a65:68cb:0:b0:460:b552:fbf4 with SMTP id k11-20020a6568cb000000b00460b552fbf4mr1869524pgt.457.1666085353894; Tue, 18 Oct 2022 02:29:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666085353; cv=none; d=google.com; s=arc-20160816; b=J2DlTD4xHJPM/3DlK3f8dp3vTmA2JTQXcFT4LJTPBkz+bY110cxqWuWjHKmuKcr3CU c+SU5Ttw+JvVKnMkv+xN8gcZdGCX9i5cXqOyh54N+pPdOMgF/h/DGIzstkWN/JEkgL0x LO+O8BnoBTZZZQZsv520uSl4qmjdXkHO7CovFDirn4Wi1FmagVWj/GaRO/8qtZD9Pyfy Grwr8aAAMR/OEnDHdCnaEKmhRgtV4K14xQDZLCbcYSMrzV9PqkM8IL2SPh1a3fuDQut8 Bl3ok2UC25IaUhq3RaLPnNr/Eh5jkK7QDnrJn6AXxRWDuKS7Xvc3kM89gfgDyxb7z2tp vUCg== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=RqxmiGcyV/mYk+QnLNTvWwmJYpQlgvRrFVxVqfYig2w=; b=MyQgsFeVnqC4hRCkHmK4dGzCXoob3np59CMT0PaitYB9ZxtDoOOYFN9VNXQOeWVNlL i9FhP/jxBmy6nJLCYBvM5YDBWHJtU9bAzwYqVxCueyo6hWZM+NbOeGwEDTGk5rWAUtIO GtSeKlP+qmr2cXSG9m7tiug0apvYLLeOXaWPsRrJ4T/B6+y7hvnxcUDEf9zdQJKatwee +odZVC8m7kN3dTRR/IfmEwwM34QDfPefjX5+eN3dwCktCYTRDewdZOj7CN5vhDkNGbB0 5VBugaIo3lDVBIjri5vtx9hZN6F0AXGZAPXmtAcRi+xUtCgzVzhFvdSXNjUM+m6pu59q 8eAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=n5v+XaUq; 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 m126-20020a633f84000000b00438c97c6f78si13965751pga.180.2022.10.18.02.29.01; Tue, 18 Oct 2022 02:29:13 -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=n5v+XaUq; 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 S229844AbiJRJZx (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Tue, 18 Oct 2022 05:25:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229841AbiJRJZi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 18 Oct 2022 05:25:38 -0400 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC0523BA for <linux-kernel@vger.kernel.org>; Tue, 18 Oct 2022 02:25:29 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id l6so12798429pgu.7 for <linux-kernel@vger.kernel.org>; Tue, 18 Oct 2022 02:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RqxmiGcyV/mYk+QnLNTvWwmJYpQlgvRrFVxVqfYig2w=; b=n5v+XaUqdK0+YZuXiM/XX3batect/k3rJvwMnNLANYSL1DpJ+RImp3kOJ5HqhKUyii ooP8NryD/OQXpkXZhU024WM8KNVYn0QQCY47VPI0TA1PHLyy+8pGcoL/5Qz4K4HhdxgJ crj+l/0hqMhq2l3cDfm6MR1V8ZCaeE5z3GI3Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RqxmiGcyV/mYk+QnLNTvWwmJYpQlgvRrFVxVqfYig2w=; b=1zOcKhzQCxxu/5q4Hv2FTWYs86ZxIpiNU4kBjFkYDxobk2zLuQeQAEjnIqXOlc9T6+ XcuFZm9jhcL4n0kkqudag+XjYeg50X3YEAfn2n9RuY9ccPftTPTL7US0pMoEEWTYlWk9 d1bzCtmHVeVgIZlHrYer4/s11h8J3EAdOzVl29eKmQ9qdwmD1ucbnYd5BeJ/iQO5gr0K y3J8XTY2xD8uGad3fdpuou/nESDIbXiu1UefxfKqkk9pUQEn2r3CGgp3bVzo7RZMKExa drpqyswwqSkH8riyte6GaRKj8aZyPtbhnLVnKTWkXoVpVJMrC+a25xknYAiUbWzh5I8B wtvQ== X-Gm-Message-State: ACrzQf2a2u9VuG6BITOPfWNZnN2L604W8yhyScSSo6bydT+TEOIgjetQ 0k/rBVRiEaQS7zBRuVeDSkA6Ng== X-Received: by 2002:a05:6a00:b95:b0:565:9cbd:a7e5 with SMTP id g21-20020a056a000b9500b005659cbda7e5mr2242933pfj.74.1666085129233; Tue, 18 Oct 2022 02:25:29 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id y2-20020a170902864200b001754cfb5e21sm8170513plt.96.2022.10.18.02.25.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 02:25:28 -0700 (PDT) From: Kees Cook <keescook@chromium.org> To: Ruhl@www.outflux.net, Michael J <michael.j.ruhl@intel.com> Cc: Kees Cook <keescook@chromium.org>, Jesse Brandeburg <jesse.brandeburg@intel.com>, Tony Nguyen <anthony.l.nguyen@intel.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH v3 2/2] igb: Proactively round up to kmalloc bucket size Date: Tue, 18 Oct 2022 02:25:25 -0700 Message-Id: <20221018092526.4035344-2-keescook@chromium.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221018092340.never.556-kees@kernel.org> References: <20221018092340.never.556-kees@kernel.org> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1271; h=from:subject; bh=Lg7BoPA33TyF1N9Ak5ejRPt+aJUHR3UR0w6mwamzyDU=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBjTnEF5cGlPXkPcKPv34lox4vlIGHaJ00+4ZE1Nfh7 Om9sbOGJAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCY05xBQAKCRCJcvTf3G3AJgc8D/ 9jBTPoFwFRkggAABohaocGh+SUXdr/tnCRtpBj1FnUDptaAqftQwbSemQKe/dNGdevoTRrcqFgYYLT QMvF6A5/qBFO7QiysDelk5iQt8J81h+leDO5DJnFZkQ2HMKCT2i0KVHUBSzzYgvAIlEalNqp3hz1Ws /BqyZq+CFVZ9jGet8Pap7DAGjauTXZyOCbjcf37mi+9pUHIX0fQB74d/oUBVh22x9s0TxbJZtcp0HQ dVAL5ulwMgSTvikjYGwzlDjdZJ3n7FWqNnXLFH+h4m8JFDZnyVq7ORhWQHzsvMton83QYopI5GTn2N ltGBC4L9wK4uPtiO4+VRw7sKkcuGPIiuXo+fA9pScZopO9vTcXbXaREhQ1bqSzmSHfQTsFR3GA2WvP lrohwfZk73id4wpmWwcibd6erFkaGn3MThfnABeNAwOV4lGFLjUWgM0gd6owrwii5bUyoMwkx1fPLQ jyQKhVIjNYs5DGv1dT4HJSiGVSBdkDZb6O+84PLYpUoDGP0QXg1K0y6nG/lJz6hkW2hPflxjO+Aefo RLXTCeTG7FcKDzuUbNugmuICL8B3oUKG/iXY7fKYbVAl/2mpUgXMe2rFw3c8NBHreGhiKQpwpC/9jN CowsdSTEpdA5snuZ++ijX40XFdZFNGUxDYGavFpVpvqBV6g3PXsyeVKWYvBg== 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=ham 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?1747017115987726968?= X-GMAIL-MSGID: =?utf-8?q?1747017115987726968?= |
Series |
igb: Proactively round up to kmalloc bucket size
|
|
Commit Message
Kees Cook
Oct. 18, 2022, 9:25 a.m. UTC
In preparation for removing the "silently change allocation size"
users of ksize(), explicitly round up all q_vector allocations so that
allocations can be correctly compared to ksize().
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, Oct 18, 2022 at 02:25:25AM -0700, Kees Cook wrote: > In preparation for removing the "silently change allocation size" > users of ksize(), explicitly round up all q_vector allocations so that > allocations can be correctly compared to ksize(). > > Signed-off-by: Kees Cook <keescook@chromium.org> Hi! Any feedback on this part of the patch pair? > --- > drivers/net/ethernet/intel/igb/igb_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c > index 6256855d0f62..7a3a41dc0276 100644 > --- a/drivers/net/ethernet/intel/igb/igb_main.c > +++ b/drivers/net/ethernet/intel/igb/igb_main.c > @@ -1195,7 +1195,7 @@ static int igb_alloc_q_vector(struct igb_adapter *adapter, > return -ENOMEM; > > ring_count = txr_count + rxr_count; > - size = struct_size(q_vector, ring, ring_count); > + size = kmalloc_size_roundup(struct_size(q_vector, ring, ring_count)); > > /* allocate q_vector and rings */ > q_vector = adapter->q_vector[v_idx]; Thanks! :) -Kees
> -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of > Kees Cook > Sent: Tuesday, October 18, 2022 2:55 PM > To: Ruhl@www.outflux.net; Ruhl, Michael J <michael.j.ruhl@intel.com> > Cc: Kees Cook <keescook@chromium.org>; intel-wired-lan@lists.osuosl.org; > linux-kernel@vger.kernel.org; Eric Dumazet <edumazet@google.com>; > linux-hardening@vger.kernel.org; netdev@vger.kernel.org; Jakub Kicinski > <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S. Miller > <davem@davemloft.net> > Subject: [Intel-wired-lan] [PATCH v3 2/2] igb: Proactively round up to kmalloc > bucket size > > In preparation for removing the "silently change allocation size" > users of ksize(), explicitly round up all q_vector allocations so that allocations > can be correctly compared to ksize(). > > Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> > Cc: Tony Nguyen <anthony.l.nguyen@intel.com> > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Eric Dumazet <edumazet@google.com> > Cc: Jakub Kicinski <kuba@kernel.org> > Cc: Paolo Abeni <pabeni@redhat.com> > Cc: intel-wired-lan@lists.osuosl.org > Cc: netdev@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > drivers/net/ethernet/intel/igb/igb_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
>-----Original Message----- >From: Kees Cook <keescook@chromium.org> >Sent: Friday, October 28, 2022 11:18 PM >To: Ruhl, Michael J <michael.j.ruhl@intel.com> >Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L ><anthony.l.nguyen@intel.com>; David S. Miller <davem@davemloft.net>; >Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; >Paolo Abeni <pabeni@redhat.com>; intel-wired-lan@lists.osuosl.org; >netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux- >hardening@vger.kernel.org >Subject: Re: [PATCH v3 2/2] igb: Proactively round up to kmalloc bucket size > >On Tue, Oct 18, 2022 at 02:25:25AM -0700, Kees Cook wrote: >> In preparation for removing the "silently change allocation size" >> users of ksize(), explicitly round up all q_vector allocations so that >> allocations can be correctly compared to ksize(). >> >> Signed-off-by: Kees Cook <keescook@chromium.org> > >Hi! Any feedback on this part of the patch pair? > >> --- >> drivers/net/ethernet/intel/igb/igb_main.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c >b/drivers/net/ethernet/intel/igb/igb_main.c >> index 6256855d0f62..7a3a41dc0276 100644 >> --- a/drivers/net/ethernet/intel/igb/igb_main.c >> +++ b/drivers/net/ethernet/intel/igb/igb_main.c >> @@ -1195,7 +1195,7 @@ static int igb_alloc_q_vector(struct igb_adapter >*adapter, >> return -ENOMEM; >> >> ring_count = txr_count + rxr_count; >> - size = struct_size(q_vector, ring, ring_count); >> + size = kmalloc_size_roundup(struct_size(q_vector, ring, ring_count)); >> >> /* allocate q_vector and rings */ >> q_vector = adapter->q_vector[v_idx]; Hi Kees, Looking at the size usage (from elixir), I see: -- if (!q_vector) { q_vector = kzalloc(size, GFP_KERNEL); } else if (size > ksize(q_vector)) { kfree_rcu(q_vector, rcu); q_vector = kzalloc(size, GFP_KERNEL); } else { memset(q_vector, 0, size); } -- If the size is rounded up, will the (size > ksize()) check ever be true? I.e. have you eliminated this check (and maybe getting rid of the need for first patch?)? Thanks, Mike > >Thanks! :) > >-Kees > >-- >Kees Cook
On Mon, Oct 31, 2022 at 08:42:36PM +0000, Ruhl, Michael J wrote: > Looking at the size usage (from elixir), I see: > > -- > if (!q_vector) { > q_vector = kzalloc(size, GFP_KERNEL); > } else if (size > ksize(q_vector)) { > kfree_rcu(q_vector, rcu); > q_vector = kzalloc(size, GFP_KERNEL); > } else { > memset(q_vector, 0, size); > } > -- > > If the size is rounded up, will the (size > ksize()) check ever be true? > > I.e. have you eliminated this check (and maybe getting rid of the need for first patch?)? Hi! It looked like igb_alloc_q_vector() was designed to be called multiple times on the same q_vector (i.e. to grow its allocation size over time). So for that case, yes, the "size > ksize(q_vector)" check is needed. If it's only ever called once (which is hard for me to tell), then no. (And if "no", why was the alloc/free case even there in the first place?) -Kees
>-----Original Message----- >From: Kees Cook <keescook@chromium.org> >Sent: Tuesday, November 1, 2022 5:37 PM >To: Ruhl, Michael J <michael.j.ruhl@intel.com> >Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L ><anthony.l.nguyen@intel.com>; David S. Miller <davem@davemloft.net>; >Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; >Paolo Abeni <pabeni@redhat.com>; intel-wired-lan@lists.osuosl.org; >netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux- >hardening@vger.kernel.org >Subject: Re: [PATCH v3 2/2] igb: Proactively round up to kmalloc bucket size > >On Mon, Oct 31, 2022 at 08:42:36PM +0000, Ruhl, Michael J wrote: >> Looking at the size usage (from elixir), I see: >> >> -- >> if (!q_vector) { >> q_vector = kzalloc(size, GFP_KERNEL); >> } else if (size > ksize(q_vector)) { >> kfree_rcu(q_vector, rcu); >> q_vector = kzalloc(size, GFP_KERNEL); >> } else { >> memset(q_vector, 0, size); >> } >> -- >> >> If the size is rounded up, will the (size > ksize()) check ever be true? >> >> I.e. have you eliminated this check (and maybe getting rid of the need for >first patch?)? > >Hi! > >It looked like igb_alloc_q_vector() was designed to be called multiple >times on the same q_vector (i.e. to grow its allocation size over time). >So for that case, yes, the "size > ksize(q_vector)" check is needed. If >it's only ever called once (which is hard for me to tell), then no. (And >if "no", why was the alloc/free case even there in the first place?) Ahh, Ok, I missed the fact that size is based on ring_count. When I saw the "struct_size" I assumed that size would be the same every time and missed this point. So can vary over time, and this ksize check is needed. With that in mind these patches look good to me. Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Mike >-Kees > >-- >Kees Cook
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c index 6256855d0f62..7a3a41dc0276 100644 --- a/drivers/net/ethernet/intel/igb/igb_main.c +++ b/drivers/net/ethernet/intel/igb/igb_main.c @@ -1195,7 +1195,7 @@ static int igb_alloc_q_vector(struct igb_adapter *adapter, return -ENOMEM; ring_count = txr_count + rxr_count; - size = struct_size(q_vector, ring, ring_count); + size = kmalloc_size_roundup(struct_size(q_vector, ring, ring_count)); /* allocate q_vector and rings */ q_vector = adapter->q_vector[v_idx];