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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F34DBC54747 for ; Wed, 28 Aug 2024 00:37:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 750396B0085; Tue, 27 Aug 2024 20:37:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D9956B0088; Tue, 27 Aug 2024 20:37:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5531F6B0089; Tue, 27 Aug 2024 20:37:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 34E196B0085 for ; Tue, 27 Aug 2024 20:37:28 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A1F1C14167E for ; Wed, 28 Aug 2024 00:37:27 +0000 (UTC) X-FDA: 82499790534.15.A4C7B87 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf07.hostedemail.com (Postfix) with ESMTP id F393340014 for ; Wed, 28 Aug 2024 00:37:25 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dtdnD7A7; spf=pass (imf07.hostedemail.com: domain of kees@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724805402; a=rsa-sha256; cv=none; b=l5RF72NgAhxClyJdXLqJb+tiNagEjRnShvq5Ht12pp3r6g5rYbWhYDbQ8IQgwYy+AKUC+F gkCfXB2xPkC6C+LJ/oGfaQHEFCEnRGdL6Nx2jvKmLcL3EOX93cLShuxg7fJv2DMR6+LKXC zvNXyWaVvVlbYOEbW5JRMAxk28SfUZ4= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dtdnD7A7; spf=pass (imf07.hostedemail.com: domain of kees@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724805402; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UorFq8XzP/mEXNhJN05Z8gWt/oqgqbZIO+DjP/GF0VE=; b=re2QoBXqmNdAHFVz36Epe8U1aDrWXSSWq3YuUb3SQ7z3hbpc16FiYzl721WDuDgF93ZtuP WtmvEro0DEvrr7rURd/TwP76lPAWEePg7hSoKKwF1gD/MrVZV+Q7yj1yx6b14Rg3kwKXJw nKVOutCYYLxs0V1Wp/yLLJdgLQCP+rE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1CB25A43209; Wed, 28 Aug 2024 00:37:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EECCAC4DDEF; Wed, 28 Aug 2024 00:19:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724804380; bh=ZoyDIz63nWYpi7kgSp5N7yU52tLO9esbjOR04pJNKQg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dtdnD7A7NsL4pMbFwtC2SBfC8RVhRJP9WNAQvLy78pWjWCPOVs/B4zGwI0FqY8JRU bgAbYXiozbSt1NvLkB5p7DCKTvBckJdwZK44PyoAJBjxY7r2wWsLnytSDoglhsHzYt o8oXbN2PDIJUBkK0/ueRACpFtnpx+W8hWU3KwQA/5FBmm6Vz4NS/d9Xeb2OfcrqkIq asNLlP3AgZq84n+E8qXDJoIGqqSpBQz0XdxSaXy05Pm/cFmpLXZ4/3jUvWfewWDH9z LgTm4YfbPiWf6VTbL83e4sQOh1JpyvYLxWaZFZlTjRiZw8H/l9/uPN1abcRhWS3mcZ edqhHRikuJgVQ== Date: Tue, 27 Aug 2024 17:19:39 -0700 From: Kees Cook To: Vlastimil Babka Cc: Linus Torvalds , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Gustavo A . R . Silva" , Bill Wendling , Justin Stitt , Jann Horn , Przemek Kitszel , Marco Elver , linux-mm@kvack.org, Nathan Chancellor , Nick Desaulniers , linux-kernel@vger.kernel.org, llvm@lists.linux.dev, linux-hardening@vger.kernel.org Subject: Re: [PATCH v3] slab: Introduce kmalloc_obj() and family Message-ID: <202408271709.31D322019@keescook> References: <20240822231324.make.666-kees@kernel.org> <5c3852e6-4a6a-42d8-85ff-8c1605939454@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c3852e6-4a6a-42d8-85ff-8c1605939454@suse.cz> X-Stat-Signature: 4tr3g4uqr4mbqzspds1scbxp366u4f3q X-Rspamd-Queue-Id: F393340014 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724805445-603317 X-HE-Meta: U2FsdGVkX18r4syOwtboETYpsQb9gJHKjSvKm7m5pUMmvQcA27ObpvXG8VZ/CtTJrsEO6M+vbU/jGvchgO3nT2czimVOV+wVMjhIrScl1hGSvBTxRu0q7PO/0fHlMNiU5dFAn7Yk5WThzsjpEy5NHqBsnrTkB+Iun8+pdQ1m7j7XJhUqLYDVfPhrbxXnbuWHCUXgQtKmxpuUPKcejh6pt6jqrVkCf2U95f0ELiCEmzfK2mqPppp2v1xCY3fgDvh5UKQnp12kznBYgxmLHNTOXW4Ai8CMZOnbmdDS9m9Q54ZXisgZYrk8E50wAFK5SBAfmevDNvvpPjLSeZUbeVfn56Oe+lnDCUmzytz/5FOEGE1RGEm3IcY0spwAyFP4hFbaw72LexvHUbCm71iE+lMAN3A09jJG6YjO2QTpOeGcQ7MOx4/IRRER3L6ZcOIOhc09gJUbBYfn6ewEqDZAzF1BvMj+Pjsl1mWGWxm1ndcS5TAO/qV0+iYsF2EmuWdx52QZ63b4CuLDxbExap7/juVFoDnm8yJbNKQWBop/nithIIl4+MKgAJSXBnzrEIMpu+L1h6/LnSxRgybVWb+PUCoKGeO/bMyH0/SvFT7CyF3bK+7i5u/U5j5opvv1ljAoQ0ssNbmFdZZnq+9jT8pwkMTV26lmjCCWzk0R9A1LAOmRDoKxwm5NTwgVVGhcrUWYVMr4ErIpdTUBJXFUyLmQfYWspQUaSaX7JhotAcGlyidQ7xODk7KXIP8/6h7OCwns3/I5wqA4Q1qalXTBG+FrZedZfpsJSa9QdXsEhQXmqZ2J4N7/mSDyY2REO8eXKAvtf1ZynkNbqIm45MrXv0WKGgggnIYIp8feA+8UsYpMPgkLV4kphGAP3Xxo72I3Tt6FdWcSPNE81j1Syj52r5MIMOaCewvoiD+DULBXmXrlDcoTEKWH3P5HmdOfa77TifEYaTGjC/LJ077IxWhkaMxsv5w /d7RZuNM j+fbaK8T/CNwRZ5f93PfARjP/bSz2sHUy/FbWGybVTZfJ36fexruUWLXDaS1LzvMvjXQg7ZwjmzRlRVRIMWX8BpKh1Ly1Phbu7lFLKxKYzMOc90imlH8pDPYra9Vg+ghJMnyMtiWlz0kx5sDSAfumwZWu9FLK4p/qKHZG2hRvNedgFK1yJvPQHjMSyt0goTPCyds0L4WhliOxIqTjTVjf7QQGqxXUzJMOzR+KssDAxX9eoecojBrVxONrggkYiITEQ221QddOILxjk+qan2sexXwfa4fFevYgBTJK0LvXJ0xzxd2wynQENoJfhJfOkfiPpikVydPy7W///j/4T9C4S/7RP/Say6mIaN9yhB+uazUZFwWyZlwCxKhCpg== 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: List-Subscribe: List-Unsubscribe: On Tue, Aug 27, 2024 at 11:32:14PM +0200, Vlastimil Babka wrote: > +Cc Linus > > On 8/23/24 01:13, Kees Cook wrote: > > Introduce type-aware kmalloc-family helpers to replace the common > > idioms for single, array, and flexible object allocations: > > > > ptr = kmalloc(sizeof(*ptr), gfp); > > ptr = kzalloc(sizeof(*ptr), gfp); > > ptr = kmalloc_array(count, sizeof(*ptr), gfp); > > ptr = kcalloc(count, sizeof(*ptr), gfp); > > ptr = kmalloc(struct_size(ptr, flex_member, count), gfp); > > > > These become, respectively: > > > > kmalloc_obj(ptr, gfp); > > kzalloc_obj(ptr, gfp); > > kmalloc_objs(ptr, count, gfp); > > kzalloc_objs(ptr, count, gfp); > > kmalloc_flex(ptr, flex_member, count, gfp); > > This is indeed better than the previous version. The hidden assignment to > ptr seems still very counter-intuitive, but if it's the only way to do those > validations, the question is then just whether it's worth the getting used > to it, or not. We could make the syntax require "&ptr"? As for alternatives, one thing I investigated for a while that made several compiler people unhappy was to introduce an builtin named something like __builtin_lvalue() which could be used on the RHS of an assignment to discover the lvalue in some way. Then we could, for example, add alignment discovery like so: #define kmalloc(_size, _gfp) \ __kmalloc(_size, __alignof(typeof(__builtin_lvalue())), _gfp) or do the FAM struct allocations: #define kmalloc_flex(_member, _count, _gfp) \ __kmalloc(sizeof(*typeof(__builtin_lvalue())) + sizeof(*__builtin_lvalue()->_member) * (_count), gfp) Compiler folks seems very unhappy with this, though. As I can recognize it creates problems for stuff like: return kmalloc(...) Of course the proposed macros still have the above problem, and both to use a temporary variable to deal with it. So, really it's a question of "how best to introspect the lvalue?" > [...] > > by GCC[1] and Clang[2]. The internal use of __flex_count() allows for > > automatically setting the counter member of a struct's flexible array > > But if it's a to-be-implemented feature, perhaps it would be too early to > include it here? Were you able to even test that part right now? There are RFC patches for both GCC and Clang that I tested against. However, yes, it is still pretty early. I just wanted to show that it can work, etc. (i.e. not propose a macro with no "real" benefit over the existing assignments). > [...] > > Replacing all existing simple code patterns found via Coccinelle[3] > > shows what could be replaced immediately (saving roughly 1,500 lines): > > > > 7040 files changed, 14128 insertions(+), 15557 deletions(-) > > Since that could be feasible to apply only if Linus ran that directly > himself, including him now. Because doing it any other way would leave us > semi-converted forever and not bring the full benefits? Right -- I'd want to do a mass conversion and follow it up with any remaining ones. There are a lot in the style of "return k*alloc(...)" for example. > [...] > > +#define kvmalloc_obj(P, FLAGS) \ > > + __alloc_objs(kvmalloc, P, 1, FLAGS, NULL) > > Wonder if there is really a single struct (not array) with no flex array > that could need kvmalloc? :) Ah, yes, Good point. I was going for "full" macro coverage. :P Thanks for looking at this! -Kees -- Kees Cook