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 51EB5C54FB3 for ; Mon, 26 May 2025 11:14:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5B146B007B; Mon, 26 May 2025 07:14:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0BE06B0082; Mon, 26 May 2025 07:14:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B22406B0083; Mon, 26 May 2025 07:14:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 923D76B007B for ; Mon, 26 May 2025 07:14:19 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0551B12018B for ; Mon, 26 May 2025 11:14:19 +0000 (UTC) X-FDA: 83484800238.16.96D0500 Received: from fanzine2.igalia.com (fanzine2.igalia.com [213.97.179.56]) by imf24.hostedemail.com (Postfix) with ESMTP id C5C9E18000C for ; Mon, 26 May 2025 11:14:16 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=igalia.com header.s=20170329 header.b=dOgOkcgW; dmarc=pass (policy=none) header.from=igalia.com; spf=pass (imf24.hostedemail.com: domain of bhsharma@igalia.com designates 213.97.179.56 as permitted sender) smtp.mailfrom=bhsharma@igalia.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748258057; 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=sRNyPwXExErBy/8kJGAzUEFc8FCKqjhWu+hUzGskcX8=; b=okn3jShQesHvzrJCLB1hS8OwwM1ZfQZT2t94THgLrptqgxkm5DpM5lguxwYqwOK4VnHVx/ tP4yIief7TPiGkWVuNNHHIK2RfLiEbbPmsIuOoknBvjS8HYPHhcrHB1S7dSMjQH8YTZ/gn 308GMUTEJebK4SkHh14zndEKh1UTUpE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748258057; a=rsa-sha256; cv=none; b=HWTHHXtUlz0MndhmtCPWNOc9nRPf/wNqj4SBwuO1rIzpiyKjagNqjCW0oYU5NwxUcYSEuG sNhXnh2hM8uToLE/9h7V2ltjNNwG2mFYYxF7Nzyff5yFwer8PmmFtGpP9M3oVRK1y3XAvH 7c+Yuwlgacb/JBbJlj9OsAR02XcN7bw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=igalia.com header.s=20170329 header.b=dOgOkcgW; dmarc=pass (policy=none) header.from=igalia.com; spf=pass (imf24.hostedemail.com: domain of bhsharma@igalia.com designates 213.97.179.56 as permitted sender) smtp.mailfrom=bhsharma@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:From: References:Cc:To: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=sRNyPwXExErBy/8kJGAzUEFc8FCKqjhWu+hUzGskcX8=; b=dOgOkcgW3891K46lC3h/P8Giqy j5wpFWLFbNsIvtu/CSMhuFpyXc2GMmf/qW7htsdUuVeQHy4WDIcUcklGJ/ViGPPunnUieV9Q4IDtY 70vmdgOjsG/48WsDWWmRsgX30TeD25TnjOsUCjtkWJ8k3jGqeGKxRcEtaaR8bnvQ6O//TGBBuqxEm T9eJVseaQnlwEULmm3DUUsYFcCO4JUm3QzyGMhJ7MbX7DRjfIxy6Nuz+t721q3JL8uYv2FRdti1TE iXAOOvdxAotvmC56UVFnZM0j6AKJPYx3gSPt4AVRPNX7xCbTzeO3zT+lJmLdb3I0e/ttaelmWVQne f2AjMJBg==; Received: from [223.233.79.88] (helo=[192.168.1.12]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1uJVmL-00DHZz-KJ; Mon, 26 May 2025 13:14:01 +0200 Message-ID: <1bc43d6c-2650-0670-8c2a-25e8d36cfb7c@igalia.com> Date: Mon, 26 May 2025 16:43:52 +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' Content-Language: en-US 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 References: <20250521062337.53262-1-bhupesh@igalia.com> <20250521062337.53262-4-bhupesh@igalia.com> <202505222041.B639D482FB@keescook> <202505231346.52F291C54@keescook> From: Bhupesh Sharma In-Reply-To: <202505231346.52F291C54@keescook> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C5C9E18000C X-Stat-Signature: etbxdtkb8qn38fxepxxgbfw5czpzr7dr X-Rspam-User: X-HE-Tag: 1748258056-621211 X-HE-Meta: U2FsdGVkX1+dECIsfi4gXve51o/quZCk0025XIHH/TtXL9ymGkw+huICk0UotO4PCvAIynWr5oDP8rB1Q+pRBSlHLzoQdx83bBQ9GNXMj1xtvOTzh//9IZrboeimbbzakmttQKqvjAs2Y49Y5ABLXqfLmQmGaoY1cFEkAAifsVWIovHfITTba68ax+L+aKxN11n3P6/A7NdYynhfnQugT5e8JdZA1ENpU57cdMcxtRa0xdo/oslfnBbDcLQe+JvwcXPDnV5usscYu5U5CbvBotvwCuSo99/6ceUefwU++xlY4zi2dTNm3Hy/Hrg2K+SrAwRTl7A/aqDaqB5kRY8YDr0duUauQKpYnESO1frNwdH/Wr6wVAXy7wP+w6gqL7vXykI1r/CkJbAeKvorUaWEOTScvNTKv2DNAYnmy6i0zYMvJQh7YkaBrFX8OIIUznRnrGWHbwyHUtHtN5OWHOElyJzNFBgfXXwuVg5HVfH0h4hcL22eCwJhglDpZwviG//VnD2/VaB8m4Fd9jRI8k4dFIT0lV3/isl+k4vpXn52tiFdbakYwv4S8Y6gVPP8utCAP5byVKRJ/i2OOciJ91R/eCCDoh9MfdiRTq8VljvuFU8lR7R8uxl9pNXlEi8ZYmVyzjCnoMNMZBFKAKu/I4RERKlZHd/Kl/BTAYsMDpbjeaTSwH34w3BO8Dn4zBeLKdiyJ9Taf1lSVUR6mMjQh+4NGpJUxmNJK2tJeJKZaK+hsHK7uBUxh6GaRa+sCpHtarsSsvPk3DJjSI5zSH3U0RyU+oIQTuqxc5zuWeQckXMxTQappIyO0CKkG8bX3+SzSdKoYT9sz+8n4qep7ALgvHXXFOA5w05p63wddxMuUxVeYmevYv864JEgIr5nHfiCTvXOUwpLSRVe7OzGxOugIrWMurVX+zV12dIxGlcAF9OHtcSYYEgqT+uJfCQlyIgZcfj6okRxL5UkGUrZZ2XhG7c F6aRA9hT 8IHCdhVvKtgsQhBwIUgS9v9z9BbCmOHJIXCJyTk5aG+RZgAi6N3Gx1W1QOa7WXki2JZdGDAGPjf3FYz0g/3AGzhJNduKvv9z+OqhfGfPLFfJ5tb7yDpPGhKEwdH5o9FtKW/Uv/J5gBIRgVCEDNSl9pK/UjbA+Myi4ut7IaTOUWdSInaztRqImSBq+bP2YGEbLK1Zpfo64sUNyPZX3iGYXK1WUXJ66lrNHmkiPbBEdPVgcT5mkt/3l9xHSkbK9DvA/SCbgXyOQrgKTxoNzADLY7pj0RvRORukh9T53rgLmw9pt/HEDBcXDn3RY97Q61tcWM46PiJBg3QqIRaavMPb+e6jP/O1aEBAbUPpkYRAkiALuApnjEJLZzdm8ww== 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: 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. Thanks, Bhupesh