From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE01C66E8 for ; Thu, 22 Sep 2022 15:55:21 +0000 (UTC) Received: by mail-pl1-f172.google.com with SMTP id f23so9178052plr.6 for ; Thu, 22 Sep 2022 08:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date; bh=5YOa+gv1sIPcp5S2eMDxZrJPz51jsjFGvspNVL+ych0=; b=LEFzWbqksCDh4S4OiJrbR7XAYMyOC2rDNgEzxm4wNn6u+IvIuPSxz7ChVzcXYCA9kN JUv48f4jgPup+CHrzZf6w+AfSyBn13B+QQpM2W85KtMMefowgfzF6SEkXu9wDa88gO2B nN2k3CYK4Hh5e/4TzZfHnbEaM6zaDEwuByIkk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=5YOa+gv1sIPcp5S2eMDxZrJPz51jsjFGvspNVL+ych0=; b=M95FNWIGBm2dLB2O9RmraHxK2nKqVKB2lPe65qbOAuy2eZAb6wOqO1P2dK7QL8OVxS 4DEZRLVctJiETQMVjUp4itX61Oqjsrp/nixKR2fYq1IffYntdZ4onTPmc2wRrlAD7Cvq N+mXOqYvO2tWV07pnyrSJjyI4YRfqJC8VuMOdfhr1vfFuOQiEaXAtmEfJGYwNMNMQIdQ 50y1yA1eQONjTE8/Xqxt3+ajT0zd8FdHoLOxoecAqvTB68OMm69+yvRQFlFeBGH8lrvF Iu888LPDTC+/0wH6brsP58Au7fznZceyJGNz5FRrIOC05N02cO57FFH8zs/GZuX/Pex4 VTFw== X-Gm-Message-State: ACrzQf1lUYhx4o+vJMZO1IGdjH5N+u+Rb81xGCZsvBTl2Z00AKQ2Paxf vpNFyiUa0iiSaombgmRf1lr3PA== X-Google-Smtp-Source: AMsMyM6pj2YmcAiXg6SonP+gJGRIk20ZQXjacFA/fb+08tqqdtojyBlUHrRZT8F0Z+9OyQ05xLAwxg== X-Received: by 2002:a17:90b:3ec9:b0:203:246e:4370 with SMTP id rm9-20020a17090b3ec900b00203246e4370mr15665429pjb.221.1663862121161; Thu, 22 Sep 2022 08:55:21 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id b7-20020a170902650700b001754fa42065sm4270774plk.143.2022.09.22.08.55.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Sep 2022 08:55:20 -0700 (PDT) Date: Thu, 22 Sep 2022 08:55:19 -0700 From: Kees Cook To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Vlastimil Babka , Pekka Enberg , Feng Tang , David Rientjes , Joonsoo Kim , Andrew Morton , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Greg Kroah-Hartman , Nick Desaulniers , Alex Elder , Josef Bacik , David Sterba , Sumit Semwal , Jesse Brandeburg , Daniel Micay , Yonghong Song , Marco Elver , Miguel Ojeda , linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, dev@openvswitch.org, x86@kernel.org, linux-wireless@vger.kernel.org, llvm@lists.linux.dev, linux-hardening@vger.kernel.org Subject: Re: [PATCH 00/12] slab: Introduce kmalloc_size_roundup() Message-ID: <202209220845.2F7A050@keescook> References: <20220922031013.2150682-1-keescook@chromium.org> <673e425d-1692-ef47-052b-0ff2de0d9c1d@amd.com> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <673e425d-1692-ef47-052b-0ff2de0d9c1d@amd.com> On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote: > Am 22.09.22 um 05:10 schrieb Kees Cook: > > Hi, > > > > This series fixes up the cases where callers of ksize() use it to > > opportunistically grow their buffer sizes, which can run afoul of the > > __alloc_size hinting that CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE > > use to perform dynamic buffer bounds checking. > > Good cleanup, but one question: What other use cases we have for ksize() > except the opportunistically growth of buffers? The remaining cases all seem to be using it as a "do we need to resize yet?" check, where they don't actually track the allocation size themselves and want to just depend on the slab cache to answer it. This is most clearly seen in the igp code: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/igb/igb_main.c?h=v6.0-rc6#n1204 My "solution" there kind of side-steps it, and leaves ksize() as-is: https://lore.kernel.org/linux-hardening/20220922031013.2150682-8-keescook@chromium.org/ The more correct solution would be to add per-v_idx size tracking, similar to the other changes I sent: https://lore.kernel.org/linux-hardening/20220922031013.2150682-11-keescook@chromium.org/ I wonder if perhaps I should just migrate some of this code to using something like struct membuf. > Off hand I can't see any. > > So when this patch set is about to clean up this use case it should probably > also take care to remove ksize() or at least limit it so that it won't be > used for this use case in the future. Yeah, my goal would be to eliminate ksize(), and it seems possible if other cases are satisfied with tracking their allocation sizes directly. -Kees -- Kees Cook 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 BD0C5C54EE9 for ; Thu, 22 Sep 2022 15:55:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CEE1510EC3E; Thu, 22 Sep 2022 15:55:24 +0000 (UTC) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by gabe.freedesktop.org (Postfix) with ESMTPS id BCBE710EC3E for ; Thu, 22 Sep 2022 15:55:21 +0000 (UTC) Received: by mail-pl1-x634.google.com with SMTP id b21so9173786plz.7 for ; Thu, 22 Sep 2022 08:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date; bh=5YOa+gv1sIPcp5S2eMDxZrJPz51jsjFGvspNVL+ych0=; b=LEFzWbqksCDh4S4OiJrbR7XAYMyOC2rDNgEzxm4wNn6u+IvIuPSxz7ChVzcXYCA9kN JUv48f4jgPup+CHrzZf6w+AfSyBn13B+QQpM2W85KtMMefowgfzF6SEkXu9wDa88gO2B nN2k3CYK4Hh5e/4TzZfHnbEaM6zaDEwuByIkk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=5YOa+gv1sIPcp5S2eMDxZrJPz51jsjFGvspNVL+ych0=; b=ZUT9tucwa/iXj8yjd61MtKDykl0WM/X0kPE2Vtc1YoDaC0K4wgrpWH/jpjrUOZCrnb cMTfBg8REf2241Gx0FyfR/44ftA/uZzS0DiZTjBhUxQPMt/bhy58uP7E7ydCGN5+9xv0 6/Aj75V8pwwnAz7p/3XzjBS6l7xMIUXMUnmWm8HGd1A4oZesk/sSByLDrMAKQWxq5pGi b9AhldGYZPRp1Cey1Bpeylt85QswARNZqme13fm+3oburu8zpVnKbRR0vyY+qMpYUyhJ PDU0QC7Hb1pfX9l7hUo5xIUfDMtJM2UCpPPzklbk4rqQq1bNgUm/qynTqhuyTRxFYwNU qJFQ== X-Gm-Message-State: ACrzQf2Gv1S9WPwf9HfofODJ1I+ES0OQWuNG7nAHgrVvmUVaJxlOhONr tohc1wgDlLRQBkL7+NQGMdAeLw== X-Google-Smtp-Source: AMsMyM6pj2YmcAiXg6SonP+gJGRIk20ZQXjacFA/fb+08tqqdtojyBlUHrRZT8F0Z+9OyQ05xLAwxg== X-Received: by 2002:a17:90b:3ec9:b0:203:246e:4370 with SMTP id rm9-20020a17090b3ec900b00203246e4370mr15665429pjb.221.1663862121161; Thu, 22 Sep 2022 08:55:21 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id b7-20020a170902650700b001754fa42065sm4270774plk.143.2022.09.22.08.55.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Sep 2022 08:55:20 -0700 (PDT) Date: Thu, 22 Sep 2022 08:55:19 -0700 From: Kees Cook To: Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: [PATCH 00/12] slab: Introduce kmalloc_size_roundup() Message-ID: <202209220845.2F7A050@keescook> References: <20220922031013.2150682-1-keescook@chromium.org> <673e425d-1692-ef47-052b-0ff2de0d9c1d@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <673e425d-1692-ef47-052b-0ff2de0d9c1d@amd.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Feng Tang , linux-wireless@vger.kernel.org, llvm@lists.linux.dev, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Eric Dumazet , linux-hardening@vger.kernel.org, Sumit Semwal , dev@openvswitch.org, x86@kernel.org, Jesse Brandeburg , intel-wired-lan@lists.osuosl.org, David Rientjes , Miguel Ojeda , Yonghong Song , Paolo Abeni , linux-media@vger.kernel.org, Marco Elver , Josef Bacik , linaro-mm-sig@lists.linaro.org, Jakub Kicinski , David Sterba , Joonsoo Kim , Vlastimil Babka , Alex Elder , Greg Kroah-Hartman , Nick Desaulniers , linux-kernel@vger.kernel.org, Pekka Enberg , Daniel Micay , netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , "David S. Miller" , linux-btrfs@vger.kernel.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote: > Am 22.09.22 um 05:10 schrieb Kees Cook: > > Hi, > > > > This series fixes up the cases where callers of ksize() use it to > > opportunistically grow their buffer sizes, which can run afoul of the > > __alloc_size hinting that CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE > > use to perform dynamic buffer bounds checking. > > Good cleanup, but one question: What other use cases we have for ksize() > except the opportunistically growth of buffers? The remaining cases all seem to be using it as a "do we need to resize yet?" check, where they don't actually track the allocation size themselves and want to just depend on the slab cache to answer it. This is most clearly seen in the igp code: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/igb/igb_main.c?h=v6.0-rc6#n1204 My "solution" there kind of side-steps it, and leaves ksize() as-is: https://lore.kernel.org/linux-hardening/20220922031013.2150682-8-keescook@chromium.org/ The more correct solution would be to add per-v_idx size tracking, similar to the other changes I sent: https://lore.kernel.org/linux-hardening/20220922031013.2150682-11-keescook@chromium.org/ I wonder if perhaps I should just migrate some of this code to using something like struct membuf. > Off hand I can't see any. > > So when this patch set is about to clean up this use case it should probably > also take care to remove ksize() or at least limit it so that it won't be > used for this use case in the future. Yeah, my goal would be to eliminate ksize(), and it seems possible if other cases are satisfied with tracking their allocation sizes directly. -Kees -- Kees Cook 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 smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.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 2B52EC6FA82 for ; Thu, 22 Sep 2022 15:55:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id AA03441032; Thu, 22 Sep 2022 15:55:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org AA03441032 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1663862127; bh=IyF9P8aHrt4taI+n7S4takNF+9VyUCBmsLlAGDuXs8U=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=APpNZjpOqm/nRYSuw4AzKMTXZiVMo0w6dTj7nQoytJ0SM6jQ7jMWb7IPr3gYoPor9 AhlCi2bhQQiQhnYg11z1NeXI/7JV0J1OBS6O6B2RwzZklaYJVfoPFLSDgJ5hFBZQnH 2kh2u5rvhCRj0fZMrBpLZdj9Y748vUpV/aHiXsFhvkizRd+NwhamTc4yA6KX2yOQpn AEOEffdalJGpncZCKqxzlBrawPgDtdtEzV7H2KPnr2vSXTAx6A56OLgIgQb9WS+XDh bggxErLpau5k8uKARWjKIEpXDnm0KJbwfpM3JL6q4ejQuN3mtGd5GNL1xXKSlhdsGG YsAZ31iCNDjcA== X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oWFssUqOIig; Thu, 22 Sep 2022 15:55:26 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp2.osuosl.org (Postfix) with ESMTP id 884304055F; Thu, 22 Sep 2022 15:55:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 884304055F Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by ash.osuosl.org (Postfix) with ESMTP id B6C2E1BF359 for ; Thu, 22 Sep 2022 15:55:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 8BFF541BC3 for ; Thu, 22 Sep 2022 15:55:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8BFF541BC3 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL6p_y8goYVZ for ; Thu, 22 Sep 2022 15:55:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CB73E41B33 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by smtp4.osuosl.org (Postfix) with ESMTPS id CB73E41B33 for ; Thu, 22 Sep 2022 15:55:21 +0000 (UTC) Received: by mail-pl1-x634.google.com with SMTP id c24so9190070plo.3 for ; Thu, 22 Sep 2022 08:55:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=5YOa+gv1sIPcp5S2eMDxZrJPz51jsjFGvspNVL+ych0=; b=XBOnEXswCSdccae8taHqbFn0wA2OgMyJeMSvIB5AdvcJxL++LPJOHpvBYYv0Nwivg/ yRqeDooRUDCCG9DqKHvugpPPpygSyaETHx0yWLBdBFr5PqwpUw32s7pZ+U64NuZe78jT qPm3xzniCjppGkjaAK88kDTeAefUbTyJjALDq9tiDAZw5Zto4wvJ040Zlv5CVbL6Roa1 fDy7pa36eQYAoV6nrCll6efUbIiB+q3HFWAm/S2xGTRhehsKkFrxAuh86mBOcsVyU+DZ Ad6SQ9S3cB4UOFQNVYDAo3BiK60bNWGCil2a7gCpYKzdDvzWyYDBViptf80ct/wDIDRu GKuQ== X-Gm-Message-State: ACrzQf0fMmJRvvLm6P+IFZ03PrACviHWwIQsRq7uCpyALuhhvR0WuAj3 qH8ueTy4H6yv9iMRM8sJneE4vQ== X-Google-Smtp-Source: AMsMyM6pj2YmcAiXg6SonP+gJGRIk20ZQXjacFA/fb+08tqqdtojyBlUHrRZT8F0Z+9OyQ05xLAwxg== X-Received: by 2002:a17:90b:3ec9:b0:203:246e:4370 with SMTP id rm9-20020a17090b3ec900b00203246e4370mr15665429pjb.221.1663862121161; Thu, 22 Sep 2022 08:55:21 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id b7-20020a170902650700b001754fa42065sm4270774plk.143.2022.09.22.08.55.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Sep 2022 08:55:20 -0700 (PDT) Date: Thu, 22 Sep 2022 08:55:19 -0700 From: Kees Cook To: Christian =?iso-8859-1?Q?K=F6nig?= Message-ID: <202209220845.2F7A050@keescook> References: <20220922031013.2150682-1-keescook@chromium.org> <673e425d-1692-ef47-052b-0ff2de0d9c1d@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <673e425d-1692-ef47-052b-0ff2de0d9c1d@amd.com> X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date; bh=5YOa+gv1sIPcp5S2eMDxZrJPz51jsjFGvspNVL+ych0=; b=LEFzWbqksCDh4S4OiJrbR7XAYMyOC2rDNgEzxm4wNn6u+IvIuPSxz7ChVzcXYCA9kN JUv48f4jgPup+CHrzZf6w+AfSyBn13B+QQpM2W85KtMMefowgfzF6SEkXu9wDa88gO2B nN2k3CYK4Hh5e/4TzZfHnbEaM6zaDEwuByIkk= X-Mailman-Original-Authentication-Results: smtp4.osuosl.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256 header.s=google header.b=LEFzWbqk Subject: Re: [Intel-wired-lan] [PATCH 00/12] slab: Introduce kmalloc_size_roundup() X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Feng Tang , linux-wireless@vger.kernel.org, llvm@lists.linux.dev, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Eric Dumazet , linux-hardening@vger.kernel.org, Sumit Semwal , dev@openvswitch.org, x86@kernel.org, intel-wired-lan@lists.osuosl.org, David Rientjes , Miguel Ojeda , Yonghong Song , Paolo Abeni , linux-media@vger.kernel.org, Marco Elver , Josef Bacik , linaro-mm-sig@lists.linaro.org, Jakub Kicinski , David Sterba , Joonsoo Kim , Vlastimil Babka , Alex Elder , Greg Kroah-Hartman , Nick Desaulniers , linux-kernel@vger.kernel.org, Pekka Enberg , Daniel Micay , netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , "David S. Miller" , linux-btrfs@vger.kernel.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian K=F6nig wrote: > Am 22.09.22 um 05:10 schrieb Kees Cook: > > Hi, > > = > > This series fixes up the cases where callers of ksize() use it to > > opportunistically grow their buffer sizes, which can run afoul of the > > __alloc_size hinting that CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE > > use to perform dynamic buffer bounds checking. > = > Good cleanup, but one question: What other use cases we have for ksize() > except the opportunistically growth of buffers? The remaining cases all seem to be using it as a "do we need to resize yet?" check, where they don't actually track the allocation size themselves and want to just depend on the slab cache to answer it. This is most clearly seen in the igp code: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri= vers/net/ethernet/intel/igb/igb_main.c?h=3Dv6.0-rc6#n1204 My "solution" there kind of side-steps it, and leaves ksize() as-is: https://lore.kernel.org/linux-hardening/20220922031013.2150682-8-keescook@c= hromium.org/ The more correct solution would be to add per-v_idx size tracking, similar to the other changes I sent: https://lore.kernel.org/linux-hardening/20220922031013.2150682-11-keescook@= chromium.org/ I wonder if perhaps I should just migrate some of this code to using something like struct membuf. > Off hand I can't see any. > = > So when this patch set is about to clean up this use case it should proba= bly > also take care to remove ksize() or at least limit it so that it won't be > used for this use case in the future. Yeah, my goal would be to eliminate ksize(), and it seems possible if other cases are satisfied with tracking their allocation sizes directly. -Kees -- = Kees Cook _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan