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 29896CFA769 for ; Fri, 4 Oct 2024 11:18:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 386CB6B040A; Fri, 4 Oct 2024 07:18:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 336026B040B; Fri, 4 Oct 2024 07:18:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 24C626B040C; Fri, 4 Oct 2024 07:18: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 F34B76B040A for ; Fri, 4 Oct 2024 07:18:57 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1FF9CA159D for ; Fri, 4 Oct 2024 11:18:57 +0000 (UTC) X-FDA: 82635672714.29.70232BB Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf13.hostedemail.com (Postfix) with ESMTP id 1E02D20003 for ; Fri, 4 Oct 2024 11:18:54 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of catalin.marinas@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=catalin.marinas@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728040639; a=rsa-sha256; cv=none; b=QmHhfsvzYmsRtIfQNN4NVZfBFAdzN50Gymq6qJ7GYjzfQMhRP22HhP2e3UQD5FgM0ig96F Imx+z8mRwLLSGokHg6ehz/tF46KxZRgsU0KWXtoXbZMRssvs6oZpWf1wsq39E3bbH9XvWE /fTZ/mcEZJogpBBZ44MylHqNgSaMkRM= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of catalin.marinas@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=catalin.marinas@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728040639; 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; bh=4Ip/RW4FqOhgp4lC5Gsi3v3VDIJP1XXaTkQAhnuidu4=; b=R1Nby9fUto1hqgZ136Q55Hyt8uLfSnMu81pUA22xFuCLK67Rd5CYyHgn5pqFtZerQd5sFD urI4aPR+SWuq564oBfXG45TVQ2zzsuXk77RwWTP67m2r8uknwvusZPy14UR8sneEle6hk1 Vb3NxJcZOo3FxT2RcNk+ah6hIMEmQK0= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8DEE0339; Fri, 4 Oct 2024 04:19:23 -0700 (PDT) Received: from arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0DE1F3F640; Fri, 4 Oct 2024 04:18:47 -0700 (PDT) Date: Fri, 4 Oct 2024 14:18:45 +0300 From: Catalin Marinas To: Mark Brown Cc: Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Thiago Jung Bauermann , Ross Burton , David Spickett , Yury Khrustalev , Wilco Dijkstra , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v13 22/40] arm64/gcs: Ensure that new threads have a GCS Message-ID: References: <20241001-arm64-gcs-v13-0-222b78d87eee@kernel.org> <20241001-arm64-gcs-v13-22-222b78d87eee@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241001-arm64-gcs-v13-22-222b78d87eee@kernel.org> X-Rspamd-Queue-Id: 1E02D20003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: bd1k45yg69poxdw99tse77qpwjnut4eg X-HE-Tag: 1728040734-699474 X-HE-Meta: U2FsdGVkX1+xDokLjWuZPEsEbesReuH/NTe6a2wNRmIrpuD/KubwJsBBqSqf6riKkos47rSzNotyJx7v0IpvHxIJ7to4XQ3A6sSDMhTmp7ebCBvJ20LII0osE8+33X1mPBLelftyolJpzxq0S6+eX/QyQJmzgOk4nvU0cPCu4p/g815nf4jAioQoFBtIKGZBcYNlrweg1blEz3KBE9XX5bYLnb3lt0hfhwo5RW7GcWlIeaTRmQ2FkZ/ALdreE6tSuoznRogqTDvANClIeR89uhUl7CxKyzbdTW37rgjX5R/WFrK6SvrJc4FfQwugAYkD0NF41Dim+cgzOdeS0XhmfYzrdlDH28v5ycoHPx3H8LeJ8sf/5zdn2n2HWL4tdDGPdBJGPEidz9EjlZ8UvfkoZefhk8q0jSvJF27id1EuxRP7izjGczEx0txef+elLA3dAvlzZ7JrxWTBHSsFNsvMtKgZN2kGwVVE+j6EZdEx2om7JfC64YJ1d8XLU93Z2V4SZzoxDdw8dfd2Id7+4DERjMObEuJg4BgANtKH0sCer+dxKu/TjMdmtOzHXITj+yDWXa9qVwqlnndqgIxVO6/9U/kZ9mHmV9Hcm2wetaWNU/ABxkfpF3n1JrKgXUQFIlbRk3kM3RATZyQ2Rpvpsz2S1EGvMUptW6T+a9fiAENrLFyjrGLHyXiA150ltaiE7y2AY/DW6GgWF3VQkOTKEZD1UqeNXul/vU2LR+zi0jvveYgPB+dJtieqeVnMXDOHiV6MOPI3KLsed6pUAiXEGW5B6tj6xe/U0O2T020XwwbIL0KPZHPU3Kjte3IkcS0TchuzsrfBm0fNNl4tuDlW+SqCwasgQHEgzSyZXbQrUw8PqgmptiIzui+zehlhwvnCYRb3IbBUTvWClSj7DUWYHs5PPsNllZtj6y0BxaNy6+myYi8itlSe/x18LRVzjdQkw5TfWhcXSncBG1E3qy3AQxg vmihvr1W fWp8WcGP2iPZZry+2tt/371JhagXyVs5n2CMWdMYXBfRdHJloGND2gVKu59TIBeKMZXTmOxWl0io7zFQJ87IWd6M4fLKM0c9i3+csw9lOUYHxQX2wEhZvK2q9v00gYp5qHmkg0Hg9ZZVsMtwDjNRHKcdcvXPwRTwOvlUpNYYIbwrRdMkApyS9trsa5im9hcZYtgVceyet6jH4fugz/1NYdF0v6iRifUocEmuL3+1tBYZpXVyrV9mWamtzuRGZmoH+SiF61iQ02vgNQtD3yyww4m40jV1XvBwC87Be 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, Oct 01, 2024 at 11:59:01PM +0100, Mark Brown wrote: > When a new thread is created by a thread with GCS enabled the GCS needs > to be specified along with the regular stack. > > Unfortunately plain clone() is not extensible and existing clone3() > users will not specify a stack so all existing code would be broken if > we mandated specifying the stack explicitly. For compatibility with > these cases and also x86 (which did not initially implement clone3() > support for shadow stacks) if no GCS is specified we will allocate one > so when a thread is created which has GCS enabled allocate one for it. > We follow the extensively discussed x86 implementation and allocate > min(RLIMIT_STACK/2, 2G). Since the GCS only stores the call stack and not > any variables this should be more than sufficient for most applications. > > GCSs allocated via this mechanism will be freed when the thread exits. I think Szabolcs mentioned a GCS leak with v12: https://lore.kernel.org/r/ZtrihWQFyb2/XrQV@arm.com (and in some private messages IIRC) Has this been identified? The changelog only mentions a leak in v8. -- Catalin