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 8A68EC54ED1 for ; Fri, 23 May 2025 20:55:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 150186B0096; Fri, 23 May 2025 16:55:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 128856B0098; Fri, 23 May 2025 16:55:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03D2A6B0099; Fri, 23 May 2025 16:55:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D39536B0096 for ; Fri, 23 May 2025 16:55:28 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7B3721CB982 for ; Fri, 23 May 2025 20:55:28 +0000 (UTC) X-FDA: 83475378336.23.92E130A Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf08.hostedemail.com (Postfix) with ESMTP id DC1DC16000A for ; Fri, 23 May 2025 20:55:26 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cQQ6ncZo; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of kees@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=kees@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748033726; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GD5dHJ91UsqIyMVknsrgE/stv9VnU+XRsj67KLk4P2w=; b=PA4vdG1PugYDEUK/tuD+aRfvXofYJaf9FbupsITrhxMTKkLIyiRlUtbGed2AvlmUTMk93N raDBw4W2nwshPMIPEvDg3GkCqH+H0WK4EjYG3dd8Cbee2KTxq99ChUoNURypLoe1u8XrwC 3P9A4Q3eZGUIIAsa2x5qEPFgJCXws5o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748033726; a=rsa-sha256; cv=none; b=Mrk8MTJyi0sOFkiobqpYUpP60o/wg2IQk9tao8wLRyLMYSG37y84Am4OuD5/VCA3Ms8UTs a3BxWnoAZf+3Mtaqga8f46QKP/7aYzNGoQdgpX1VbJNadcoYAL89o9SC9nxKOTHbjsnSFf GX6UsgvRlZTijhEYyy8sfD2QQ1iOQkI= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cQQ6ncZo; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of kees@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=kees@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 28FDF61154; Fri, 23 May 2025 20:55:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB533C4CEE9; Fri, 23 May 2025 20:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748033725; bh=IVHWS6tnx7kSx36MbDnXyPj4cHHcdGh60Uex+YeiCpw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cQQ6ncZoroWoXs1C/8kkHXXpG4VwSvsmRe7qDXLyEe2ZEUhKweSWRjxgE8AYy2yo/ pDNRYQzTpIUfHerMKjwyOR6WueWQ1e2kWu/6/vHryqyjeun3E5XzjUjUb5qd3ygLV3 0R/FUFasuaEROp8LOXj8Ntahg+lRKXXP/PCtFC2erPjooGebs1n9xvNnZS4F6Fbzmc ZEiG9rxCtCL60pSBXc0TLr34KB0gX5CBDkyXTG36dDPMzcxoXC0q+P4ULuEYn4C6mF 7Fi6Ktix46mXpX3v8F5DKmmIbB0ttP8lcdLCkDTL0EouwASpD5r9Uos7bAwWFpHerI X3h3ncE8+q73Q== Date: Fri, 23 May 2025 13:55:22 -0700 From: Kees Cook To: Bhupesh Sharma Cc: Bhupesh , akpm@linux-foundation.org, kernel-dev@igalia.com, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, oliver.sang@intel.com, lkp@intel.com, laoar.shao@gmail.com, pmladek@suse.com, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, arnaldo.melo@gmail.com, alexei.starovoitov@gmail.com, andrii.nakryiko@gmail.com, mirq-linux@rere.qmqm.pl, peterz@infradead.org, willy@infradead.org, david@redhat.com, viro@zeniv.linux.org.uk, ebiederm@xmission.com, brauner@kernel.org, jack@suse.cz, mingo@redhat.com, juri.lelli@redhat.com, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH v4 3/3] exec: Add support for 64 byte 'tsk->comm_ext' Message-ID: <202505231346.52F291C54@keescook> References: <20250521062337.53262-1-bhupesh@igalia.com> <20250521062337.53262-4-bhupesh@igalia.com> <202505222041.B639D482FB@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DC1DC16000A X-Stat-Signature: unfstqzc947bhfrpfz44bin8j4w97wae X-Rspam-User: X-HE-Tag: 1748033726-738702 X-HE-Meta: U2FsdGVkX1+Ogldxnv8eO8Ajxotcy1koBg3oUpteZxp6YqkTVozTi5nIsvGX7r0JhRoR3PGqecM4untujNEqWaR+/w4ftkwB6w0PH54IbM8DP71HeZtJSV/NHMVqv40WQqhqe+lrVepOayVQ+PEnApk8e14fDoDs2uXS8UkusipLVke0wKy2cKVkidtL8bpy8BmfEN+9oA5C9J8r2wybtmG+aoKOfCS2Q8pufJ4GOm2brt2SwUkuCDSLWN1TNqOl8iJBmRw+cKvXzUYrR9AG03Gc/FNzUqucO+Cf4R/C0xu2PSALNBPXOpXHYk3IdDfexBN6SAgI5v+Z2cPTsMLUx8mVs7GFrXRx5neEzzH9OpV2Ssr1kDWQ33RoDShahb9Mu/qPuWI9YMBQjs3/i3e29TfYnrqnyU9eH2djMwcWCQv1j+CqRvJKCnHgNTltxg8NWSBXOppSxMXIH25qWBJUDvepJX4P4PeHdlKORWqKTUB61SwOIzatvdObuVS8lts1J1268yS565hk0cU9LQZr4Hh91+Omxh9xOfxkn8+x3aSUsujR8mchEdRLIs4DzHE2yTaoxjHQeVcWqvp2FwX7m0SXO4JD2cCCHqhCcbu5sHzsUKb+W1rmZmuhJLg7DZ0bU1bXufBYZiHWtQkLyLtgzBz0/7kyDEW4LwP7VmNb0LWsj4icI0LtZ+C7fskB4R8m9y93PR85mmVYjIp6k74+mNYpHrU1FEFDQoA71cRCyQDHmHLX6Mi5JCCBWrIjxvI/hUBZpvCtw+X3LNZ932C1yC57/WY4lvmwi7y61H/DxfuJHKGBe5WL7dRYY8OI4zLrxOlcCt2W8noGkXd+aNwsgt/LrTKZdP3jbW3qb3U/XpnnSpqMlHXi4hTUjEenuNa3TFsJEXEl1qZydpGUXrzsfmhahwTGwgFOjamTq8ZgP/K+ouB+oKrM471KpaF/5kb5xrwnxhRvyFh9d68yRnw ZWaCd4zy T9w7UZrNjyxMpnEx5wp34wwol5k6drFVkPGragYcCGmZQTrulg60ISzINeRroG5qzqKs7SFk3iP779aqKwTsKVaaN12Gp7/4xqPV0TZA0ZkXpHhVtJZuvfQvec26ubCLpFrcjRoPGvgvQEyVxJYVMRIHs3EppRk35usENE7OMc5lQtzWX8ELXEpGPWn8t81f0V93rdsIc4RaP3ju849vzY1XokvSfgOHx4DMmyLPOB+YjczuBhUrkR1lwXDF9xOphrbbZLAA4VK8u0gFsX23yPqPHu83ep7jaBE5wsH1sHy9gME+0MOgjCEh5ZLivqCKXjK0ozZrU9atvTyxqdCKiZW1PoHVsmC7OekFRtQOO2oTrBvy3F4N9pfFpvniRK+9qEWOzJoIQtvXeono= 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 Fri, May 23, 2025 at 06:01:41PM +0530, Bhupesh Sharma wrote: > 2. %s usage: I checked this at multiple places and can confirm that %s usage > to print out 'tsk->comm' (as a string), get the longer >     new "extended comm". As an example of why I don't like this union is that this is now lying to the compiler. e.g. a %s of an object with a known size (sizeof(comm)) may now run off the end of comm without finding a %NUL character... this is "safe" in the sense that the "extended comm" is %NUL terminated, but it makes the string length ambiguous for the compiler (and any associated security hardening). > 3. users who do 'sizeof(->comm)' will continue to get the old value because > of the union. Right -- this is exactly where I think it can get very very wrong, leaving things unterminated. > The problem with having two separate comms: tsk->comm and tsk->ext_comm, > instead of a union is two fold: > (a). If we keep two separate statically allocated comms: tsk->comm and > tsk->ext_comm in struct task_struct, we need to basically keep supporting > backward compatibility / ABI via tsk->comm and ask new user-land users to > move to tsk->ext_comm. > > (b). If we keep one statically allocated comm: tsk->comm and one dynamically allocated tsk->ext_comm in struct task_struct, then we have the problem of allocating the tsk->ext_comm which _may_ be in the exec() hot path. > > I think the discussion between Linus and Yafang (see [1]), was more towards avoiding the approach in 3(a). > > Also we discussed the 3(b) approach, during the review of v2 of this series, where there was a apprehensions around: adding another field to store the task name and allocating tsk->ext_comm dynamically in the exec() hot path (see [2]). Right -- I agree we need them statically allocated. But I think a union is going to be really error-prone. How about this: rename task->comm to something else (task->comm_str?), increase its size and then add ABI-keeping wrappers for everything that _must_ have the old length. Doing this guarantees we won't miss anything (since "comm" got renamed), and during the refactoring all the places where the old length is required will be glaringly obvious. (i.e. it will be harder to make mistakes about leaving things unterminated.) -- Kees Cook