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 9D6DBC2BD09 for ; Tue, 9 Jul 2024 16:57:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D2026B0095; Tue, 9 Jul 2024 12:57:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 081F96B0096; Tue, 9 Jul 2024 12:57:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8BC16B0098; Tue, 9 Jul 2024 12:57:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CB03E6B0095 for ; Tue, 9 Jul 2024 12:57:51 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 43415A519F for ; Tue, 9 Jul 2024 16:57:51 +0000 (UTC) X-FDA: 82320821142.03.40501E8 Received: from out-189.mta1.migadu.com (out-189.mta1.migadu.com [95.215.58.189]) by imf23.hostedemail.com (Postfix) with ESMTP id EFDFB140011 for ; Tue, 9 Jul 2024 16:57:47 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="U4ZV/f49"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf23.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.189 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720544243; a=rsa-sha256; cv=none; b=RinAnM9lUx0YqFELGqPbB37bIycrHPnRpVX6mDCXGLq63CElpYXqt3kSRf5So7jXpsAt/i MQL101pGxXvimAN5dTSO2eVe3oux+1OdtdJgsJCeaymRTgu5+7/1wwh+VB9oGRnfkfjqmT ew2g8O+QycpXeLRdRufvs4+y7VdwFSo= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="U4ZV/f49"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf23.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.189 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720544243; 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=bJmYjvyHHMwqRxruumXPBbFALlX9+6N9u8Skv9IQ5wA=; b=d3FN2HT0PkoBAv+qC+CrndLb9hENOdBbDCHzAeveVqv1I0BvvEViKRgvYL+hV4DEskgBVD 9+BrfISykr99y3MhCI3wFIa7c6MqfiU8M1wEE2OYciWwFVtuS+pv+0JzXHQDqICMD3QGS4 BcBxPsbertYUq02Q28p6dIAoyi8m4tU= X-Envelope-To: kees@kernel.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1720544265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bJmYjvyHHMwqRxruumXPBbFALlX9+6N9u8Skv9IQ5wA=; b=U4ZV/f49pEThhYkusIyNy+pCsfUW4zQ+Y01qSj+aRMnxJPZdLa+rkywFl/u8vG+aA44TGd HBBFvZh8uMGTfaTpHkAX/V2yYT+knbCvnoscVDbXsS0OgDv+PfplRl97j6k+D+ZzMs1Oc+ VFcFB+I6REYZmvLPXUM85bWMz4515ng= X-Envelope-To: vbabka@suse.cz X-Envelope-To: jannh@google.com X-Envelope-To: tony.luck@intel.com X-Envelope-To: ndesaulniers@google.com X-Envelope-To: ojeda@kernel.org X-Envelope-To: elver@google.com X-Envelope-To: nathan@kernel.org X-Envelope-To: haoluo@google.com X-Envelope-To: przemyslaw.kitszel@intel.com X-Envelope-To: cl@linux.com X-Envelope-To: penberg@kernel.org X-Envelope-To: rientjes@google.com X-Envelope-To: iamjoonsoo.kim@lge.com X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: 42.hyeyoo@gmail.com X-Envelope-To: gpiccoli@igalia.com X-Envelope-To: mark.rutland@arm.com X-Envelope-To: kuba@kernel.org X-Envelope-To: petr.pavlu@suse.com X-Envelope-To: aleksander.lobakin@intel.com X-Envelope-To: tony.ambardar@gmail.com X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-hardening@vger.kernel.org Date: Tue, 9 Jul 2024 16:57:38 +0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Kees Cook Cc: Vlastimil Babka , Jann Horn , Tony Luck , Nick Desaulniers , Miguel Ojeda , Marco Elver , Nathan Chancellor , Hao Luo , Przemek Kitszel , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Guilherme G. Piccoli" , Mark Rutland , Jakub Kicinski , Petr Pavlu , Alexander Lobakin , Tony Ambardar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org Subject: Re: [RFC][PATCH 0/4] slab: Allow for type introspection during allocation Message-ID: References: <20240708190924.work.846-kees@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240708190924.work.846-kees@kernel.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: EFDFB140011 X-Stat-Signature: tufjbmdnnr5ymrwnnx9jhr5gshbbbt3z X-Rspam-User: X-HE-Tag: 1720544267-537984 X-HE-Meta: U2FsdGVkX1+ddnYF7mGZF42qJzVQAizrWqLAJVst5cmkQjesGpXbVp2/5Q6gmA3NIV1PS2TAelqDhZU8KgiS+wcl2f7d2TncXV67HkTqwkYuX4vztlrcAssJ3FKarR4lRpCosfVJk4I2MPaAMHJYUEjC0lEwuw8jBiL2tuzJ5jqgCtAQcoIfON0N7LL452QoQO5cGoJq5BctSAC9Zrt8USVlCWFvkIWMkAML/shjJiljrnGjtpBYKwSl45AVS/MaUX9owVGgVgHd4NlQRMV/YoyRP2nprmMWtjddJxjIOdhlQVaemjdx2bcURVFexDOEPhhJec2FRJxIfrfpGCb1TsbXtn9S2/NWeUbZJNQSa6plPD5ijH5YZWiYICfssMiCFnw9L07T1Dr/F+x6PlfgacoMickyEuY/Lmmajq01AqDBRU3BhCcZ8yDE6CNsBt7x4ObFAzOYQfOxU0Ztn4XTPU9/jerxS+R1WrrgEfjynw/dncb8wiq9qzIv2JinuQ4pls7wSQXLbIHiiGCqzwz9dUGP6VZaHCF7GbYHtqO1nDK34/QMRU7e13rWsq9oXzwK1cut3ynV3ym/nuSr2YhdjUMnYkCuphDgPDis0WX6mnF/866cVWu+ZCMF8VXkZmXIp6GhQhDB6qDgf1VwafyMQwaB4jBlG2ElCMUvvjfdkBUPk0sLxhCZ3nA0TgcmJSQ1v2f3sOIckutuNcCy2rGQob8/4+is01S/RST/C+yslIC0/fXExavY2rLd78IJwgC0G+PcIjud7zvjBfbY65JeDTbUwt0yPWPzBDQVwppP60ulm5SIPeCvyMOrL+hl+hF2SDbBUOikBIlQt9n5YkFANvt0gMdiaXehgzeBQBhpzbdFgAtz+I2eMC+/lLYsuUiq3G3oCL5Ca3gkiDBIcOofG9O68Qx8Bt3O50eBhpsOxxoEC6JLxMff08wkK6PGThLd/jmLXhx+xvB0ltRh4VZ ZwfGIr9P sXS6GQnOWAQalc7rTlJuXRg4fQ2wwXGOZBHPq52LRxu4a7CHBaPDJzTFfdgwXvsX/vioAY818w0mA7qTcTNGCZ7d7rSVgQxOc27f5WJjdVZpPwCRjIijeiA8bQ5mSURoxEaaqsF82hWWT4ggCtCDlXCSIoor6OgDlVFZysXZ0f+cRGjBQ+woCYgkQp6pbryJSCHSiuDZT/46GjJXVArmcY4IgRhhXq0gr1Edj 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 Mon, Jul 08, 2024 at 12:18:34PM -0700, Kees Cook wrote: > Hi, > > This is an RFC for some changes I'd like to make to the kernel's > allocators (starting with slab) that allow for type introspection, which > has been a long-time gap in potential analysis capabilities available > at compile-time. The changes here are just a "first step" example that > updates kmalloc() and kzalloc() to show what I'm thinking we can do, > and shows an example conversion within the fs/pstore tree. > > Repeating patch 3's commit log here: > > There is currently no way for the slab to know what type is being > allocated, and this hampers the development of any logic that would need > this information including basic type checking, alignment need analysis, > etc. > > Allow the size argument to optionally be a variable, from which the > type (and there by the size, alignment, or any other features) can be > determined at compile-time. This allows for the incremental replacement > of the classic code pattern: > > obj = kmalloc(sizeof(*obj), gfp); > > into: > > obj = kmalloc(obj, gfp); > > As an additional build-time safety feature, the return value of kmalloc() > also becomes typed so that the assignment and first argument cannot drift, > doing away with the other, more fragile, classic code pattern: > > obj = kmalloc(sizeof(struct the_object), gfp); > > into: > > obj = kmalloc(obj, gfp); I like the idea, however it's not as simple and straightforward because it's common for structures to have a variable part (usually at the end) and also allocate more than one structure at once. There are many allocations which look like kmalloc(sizeof(my_struct) * 2 + SOME_MAGIC_LENGTH, GFP_...) or something like this, which you can't easily convert to your scheme. The only option I see is to introduce the new set of functions/macros, something like kmalloc_obj() or kmalloc_struct(). Or maybe tmalloc()? (t for typed) Thanks!