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 4BB05C7EE39 for ; Mon, 30 Jun 2025 07:58:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E36706B0093; Mon, 30 Jun 2025 03:58:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E0DBE6B0096; Mon, 30 Jun 2025 03:58:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D232A6B0099; Mon, 30 Jun 2025 03:58:58 -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 BCECB6B0093 for ; Mon, 30 Jun 2025 03:58:58 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 76EB3105BBD for ; Mon, 30 Jun 2025 07:58:58 +0000 (UTC) X-FDA: 83611315956.01.2D7E6A6 Received: from fanzine2.igalia.com (fanzine2.igalia.com [213.97.179.56]) by imf30.hostedemail.com (Postfix) with ESMTP id 73AE680005 for ; Mon, 30 Jun 2025 07:58:56 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=igalia.com header.s=20170329 header.b=pnOwMpet; spf=pass (imf30.hostedemail.com: domain of bhsharma@igalia.com designates 213.97.179.56 as permitted sender) smtp.mailfrom=bhsharma@igalia.com; dmarc=pass (policy=none) header.from=igalia.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751270336; 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=qd6nlFnG074iKvcvvBFSCkzEyxCQmvambP47KCg+krI=; b=ohBSdNWVF1gdlykz+mHMNRsP9EgBv7tnlgbiexWi/pRYEAE8Z2pnFRgv0WB/PlYe/DyJ0H px7U5GYFVGjtHT5C7GtNn3u4KUa1LFyq3PaWUIaHTDn9cE9z+jpfl6tNhG2W68U+MPJmFm 7uwEVpLB9EXM8DBVhUmBP4vzeHNq+50= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751270336; a=rsa-sha256; cv=none; b=s/fNT2vSkywPps6ZbLG+M4HIVp7F4o1drtE6mrp2NMs185bo0cK5cG8D6m8W4Pj0C6bD2N ogV+sCeRznEYalnrMN8W7hb3IfOzhalVbEIWqisPzwc/ZNYtgpfuG2WOf19XNZu8a/ZNjM PLPfP/4UQN7KStAPx0I/4LGpw+Cbxlc= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=igalia.com header.s=20170329 header.b=pnOwMpet; spf=pass (imf30.hostedemail.com: domain of bhsharma@igalia.com designates 213.97.179.56 as permitted sender) smtp.mailfrom=bhsharma@igalia.com; dmarc=pass (policy=none) header.from=igalia.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Cc:To:From:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qd6nlFnG074iKvcvvBFSCkzEyxCQmvambP47KCg+krI=; b=pnOwMpetoLhGQsMp+XPhrwgE4A LkW7SqPS1MN9oE9UZwTFUc3L0SjeNyy9+CULklt/CwDZrQhxI5oGYMxzOmeRZ8F5PVLdDfU+UBpxR 7ILkpEWZQoeoXbyfkXKzDoG29JYlJqm6b1ZeIqCqc09xG9X5IdWBCsbM1YhtS20mQLkkN0+IBaQsK b1V8sjvjlyHZI1oE1rzfQDFqhZ4JiVaW+RCln4YWKxTZRm0NUkAZbpAqiWs5jCSIVFt5PRTbJuVNf APwPjXH/HYHykFTwKQBNdsOB6b10jxUiMjeecXJL9jLKEAV26uvuhjD3/vVFHZZ1CdPanEKhbdZ94 BD7uWUJg==; Received: from [43.224.128.131] (helo=[10.5.50.117]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1uW9PO-00ANeX-Ob; Mon, 30 Jun 2025 09:58:34 +0200 Message-ID: Date: Mon, 30 Jun 2025 13:28:25 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v4 3/3] exec: Add support for 64 byte 'tsk->comm_ext' From: Bhupesh Sharma To: Kees Cook 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, torvalds@linux-foundation.org, akpm@linux-foundation.org References: <20250521062337.53262-1-bhupesh@igalia.com> <20250521062337.53262-4-bhupesh@igalia.com> <202505222041.B639D482FB@keescook> <202505231346.52F291C54@keescook> <1bc43d6c-2650-0670-8c2a-25e8d36cfb7c@igalia.com> Content-Language: en-US In-Reply-To: <1bc43d6c-2650-0670-8c2a-25e8d36cfb7c@igalia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 73AE680005 X-Stat-Signature: c6wet6pcroyin463bnbm5g4f6tsoc7y5 X-Rspam-User: X-HE-Tag: 1751270336-784716 X-HE-Meta: U2FsdGVkX198WuoWZ979VmKMOAfzPITY9bpWA+h2JVSD9tlG8/oyqBA5VHUQYPXEbSw02YohSRIzsQd150QM9z+2yf64X3E+MW2FoTPVwU2oq7CzXKKTkfvgwDtaV5uOGJ2Z9/yhdzrkctHYSHW8Fb2TXZGtHsruPZDguKa5CaR/IAS/bIS3ZrRR2ViWJseLg/BMYOCFr0FrcQGifczlxBAQ6Lg6WAyR+cIUupE8nOO7JQqEPZxoc0vFl+mSkqd+JRRABUkIQ6/PoHNiS3ppjJK9Bf+xOP2kIH0LN5iV1eFNg/Qf0yl+E7rLwf/aId9pnnUvLA69n9goGyrjq/ZovzUJHMFT6XJLrnXnyRqyxeOqiLrjjeTMOewLcqqvmiocZ3/SuqXV+RMUkM34qRpAO2ITz33XndFE7NVWiCutdBfSWMXtDz0rFfODyzR73zNj6QSOcdqp1kkg8Rr3hI0B1pF4sPsXCPHVWBzkQKyu/PvNGWYHaRUsIQ+KDIyWZ2Gce22QrsF8iCEb5+tyBU0KA8m/c/FogiVfbPa5Aly119WVCokB7CnxSTwbjw0+YFh8ojG2pKeOWeEGwclK2sKPevh7jFS6ZBCl4Ip50twKdwU1rQ+/n37nOB85ybwqNHVFgX23dNhbRNtl2zTCB4qdRdT3w6qdOO+HJ/XuWdyGdtyP2mzyG4PgLPXdSxjfgFNFAoQTyKthhuzJiL+n+/3/pnjIVGa/OcAJmRyOwSnrQX0uWW+9g/I9ZtaT0Jed0byUlfvaQK4dZYMPEJVi+K5Fun9OjhOt0Wnn15nof9teCI3gNVOrf9lizdgfWHkrizEyfy0ESn95UftGn7pYBw9dWj5KG6qM7WkUOD/+0wou7sybei0DBjbJJxzuOhmoIn+T2RLceiPQ94+08UoyPCQZ9gzsQ+o+71KQr4jZqsvQPZcJ4hfVvepjoI35D9YrgZsQqgGGHDYtwSAe6mDUHHE xcDQkFIU YLfVQkJ1Wa4cw3GXakz4O4Ogbmrj1eEajc8+hMQyfRAqc0aABA5QZ3X37pHcqTTMoIi2FWmt0eNuerSx1hVSsbXVEePG4V1NbkUYK3yFzIk9co0v+orrmCZ7gZTI0S02w0Oaapp+GkDkm2wszzFe1ifUFfarIgpfFCXv/OBOdyJTl2H5hExhmN+MS34ErA4qdOcSoskQxou2+F8Vr7ML8B2BhLWZGssyxFVFoMKniznvVtym6T10bdRXvDTG/y21K4HWDmn5vSGd3qb4DJUV7qzmNvpivRX2tdDhFfMQwat9Q1vjjQqzJ1PHsEGNTofbQZJbIBitNLOUTIO77TLC6Yb1yOvr2TT43cAEZuzWfS3s1p9L3yafZ1/NROyIpV2eZvFsMH5ah0t87g9wK6N2sT4GehymcSvxkmUa+ 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 5/26/25 4:43 PM, Bhupesh Sharma wrote: > Hi Kees, > > On 5/24/25 2:25 AM, Kees Cook wrote: >> 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). > > Right. > >> >>> 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.) >> > > Ok, I got your point. Let me explore then how best a ABI-keeping > wrapper can be introduced. > I am thinking of something like: > > abi_wrapper_get_task_comm { > >     if (requested_comm_length <= 16) >         return 16byte comm with NUL terminator; // old comm (16-bytes) >     else >         return 64byte comm with NUL terminator; // extended comm > (64-bytes) >     .... > } > > Please let me know if this looks better. Accordingly I will start with > v5 changes. Hi Everyone, sorry for the delay but I wanted the revive this discussion after the -rc1 and my PTO. I am looking for suggestions on how to implement v5 for this series. Here is some background of the version (and related discussions so far): In the v4, the implementation for tsk->comm handling (for supporting long 64byte task names) looked at handling the possible use-cases as follows: 1. memcpy() users: Handled by [PATCH 2/3] of this series, where we identify existing users using the following search     pattern:        $ git grep 'memcpy.*->comm\>' 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". 3. users who do 'sizeof(->comm)' will continue to get the old value because of the union. The above points were taken to address the points discussed earlier between Linus and Yafang (see [1]) As Kees, suggested in the v4 review (see [2]): 1. Let's rename task->comm to something else (task->comm_str?) and increase its size, and 2. Then add ABI-keeping wrappers for everything that  _must_ have the old length. I am thinking of implementing it with something like: abi_wrapper_get_task_comm {     if (requested_comm_length <= 16)         return 16byte comm with NUL terminator; // old comm (16-bytes)     else         return 64byte comm with NUL terminator; // extended comm (64-bytes)     .... } Kindly let me know your views on the above approach(es). [1]. https://lore.kernel.org/all/CAHk-=wjAmmHUg6vho1KjzQi2=psR30+CogFd4aXrThr2gsiS4g@mail.gmail.com/ [2]. https://lore.kernel.org/all/202505231346.52F291C54@keescook/ Thanks.