From: Kees Cook <keescook@chromium.org>
To: "Christian König" <christian.koenig@amd.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Pekka Enberg <penberg@kernel.org>,
Feng Tang <feng.tang@intel.com>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Alex Elder <elder@kernel.org>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
Sumit Semwal <sumit.semwal@linaro.org>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Daniel Micay <danielmicay@gmail.com>, Yonghong Song <yhs@fb.com>,
Marco Elver <elver@google.com>, Miguel Ojeda <ojeda@kernel.org>,
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()
Date: Thu, 22 Sep 2022 08:55:19 -0700 [thread overview]
Message-ID: <202209220845.2F7A050@keescook> (raw)
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
next prev parent reply other threads:[~2022-09-22 15:55 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-22 3:10 [PATCH 00/12] slab: Introduce kmalloc_size_roundup() Kees Cook
2022-09-22 3:10 ` [PATCH 01/12] " Kees Cook
2022-09-22 11:12 ` Hyeonggon Yoo
2022-09-23 1:17 ` Feng Tang
2022-09-23 18:50 ` Kees Cook
2022-09-22 3:10 ` [PATCH 02/12] skbuff: Proactively round up to kmalloc bucket size Kees Cook
2022-09-22 19:40 ` Jakub Kicinski
2022-09-22 3:10 ` [PATCH 03/12] net: ipa: " Kees Cook
2022-09-22 13:45 ` Alex Elder
2022-09-22 15:57 ` Kees Cook
2022-09-22 3:10 ` [PATCH 04/12] btrfs: send: " Kees Cook
2022-09-22 13:30 ` David Sterba
2022-09-22 3:10 ` [PATCH 05/12] dma-buf: " Kees Cook
2022-09-22 3:10 ` [PATCH 06/12] coredump: " Kees Cook
2022-09-22 3:10 ` [PATCH 07/12] igb: " Kees Cook
2022-09-22 15:56 ` Ruhl, Michael J
2022-09-22 16:00 ` Kees Cook
2022-09-22 3:10 ` [PATCH 08/12] openvswitch: " Kees Cook
2022-09-22 3:10 ` [PATCH 09/12] x86/microcode/AMD: Track patch allocation size explicitly Kees Cook
2022-09-22 3:10 ` [PATCH 10/12] iwlwifi: Track scan_cmd " Kees Cook
2022-09-22 4:18 ` Kalle Valo
2022-09-22 5:26 ` Kees Cook
2022-09-22 3:10 ` [PATCH 11/12] slab: Remove __malloc attribute from realloc functions Kees Cook
2022-09-22 9:23 ` Miguel Ojeda
2022-09-22 15:56 ` Kees Cook
2022-09-22 17:41 ` Miguel Ojeda
2022-09-22 3:10 ` [PATCH 12/12] slab: Restore __alloc_size attribute to __kmalloc_track_caller Kees Cook
2022-09-22 7:10 ` [PATCH 00/12] slab: Introduce kmalloc_size_roundup() Christian König
2022-09-22 15:55 ` Kees Cook [this message]
2022-09-22 21:05 ` Vlastimil Babka
2022-09-22 21:49 ` Kees Cook
2022-09-23 9:07 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202209220845.2F7A050@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=christian.koenig@amd.com \
--cc=danielmicay@gmail.com \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsterba@suse.com \
--cc=edumazet@google.com \
--cc=elder@kernel.org \
--cc=elver@google.com \
--cc=feng.tang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=josef@toxicpanda.com \
--cc=kuba@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-wireless@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=ndesaulniers@google.com \
--cc=netdev@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=pabeni@redhat.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=sumit.semwal@linaro.org \
--cc=vbabka@suse.cz \
--cc=x86@kernel.org \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).