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 0D76AC3DA7F for ; Thu, 15 Aug 2024 16:40:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8681A6B0174; Thu, 15 Aug 2024 12:40:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 816CF6B0175; Thu, 15 Aug 2024 12:40:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DE4C6B0176; Thu, 15 Aug 2024 12:40:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4D2026B0174 for ; Thu, 15 Aug 2024 12:40:39 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 01FB2121557 for ; Thu, 15 Aug 2024 16:40:38 +0000 (UTC) X-FDA: 82455043398.30.796E019 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf13.hostedemail.com (Postfix) with ESMTP id 37C242002D for ; Thu, 15 Aug 2024 16:40:36 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of Dave.Martin@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=Dave.Martin@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723740024; a=rsa-sha256; cv=none; b=yuNItZbDE15zbDquC8i4aVgJtMMlkNYY28rojthwBo570KX8TiNh88ixdEaTvHGmHJfzDl Xw3VxJbhhhknhbP78k6aehrQqYsVboUqmJT0bzr3sS8JXEIy76g+BNmi6HMv8PpcA2Jko5 dxN/k3vSjsqFyfpe4Wx/h2CI5N7F20U= 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 Dave.Martin@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=Dave.Martin@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723740024; 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=J/vungWYPE46FHbRiXVMLqjflva1DGRgLIRC0krccZk=; b=ZBWHliJhVjKsgOk609Wd9wAKNYDY3DpYDb95ZERRpE+3pGqvQc4kcq81wKCBd4uYkwS4Lj MPMSxzAw5uZdxMIE6KNMTA1Ov8Rp/muAthlxnbK0hKN8VZo5XRRt9UeSCo6j20yOP2z+GC sZ4iEy5PQCX2mRkk22zA3P8IUxvoJB4= 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 01FD014BF; Thu, 15 Aug 2024 09:41:02 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3F48C3F6A8; Thu, 15 Aug 2024 09:40:30 -0700 (PDT) Date: Thu, 15 Aug 2024 17:40:27 +0100 From: Dave Martin To: Mark Brown Cc: Catalin Marinas , 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 , 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 v10 24/40] arm64/signal: Expose GCS state in signal frames Message-ID: References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-24-699e2bd2190b@kernel.org> <7433e3d2-996a-45a0-b917-666a340ad109@sirena.org.uk> <280e4455-9cf7-40e1-9114-7bb3aa9de868@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <280e4455-9cf7-40e1-9114-7bb3aa9de868@sirena.org.uk> X-Rspam-User: X-Rspamd-Queue-Id: 37C242002D X-Rspamd-Server: rspam01 X-Stat-Signature: ncb64wbm7mfib48qq6bbqkskuwx1m4i1 X-HE-Tag: 1723740036-602066 X-HE-Meta: U2FsdGVkX1+C0EbRee9cV3QHwgyN9oNqdQo5kfjYaRppJAT19DglX42U/q/zlBh0HO5UHc/cJ3xExBgywSI+MM5WU/4TsGvTNZJnaAty8sjkGYqYsAiIdpEFcR01aUDulC0TxdNxtNuKndZn2odVOC+E/80U92YSOMfGbBqlrJXtWsAr+/KozNfGtoXvmn9irX9Bui/k7UGArSp4sWRPvaBQiYSQdj1zD5tQaliQhq5J/DOtdgV77lPAg50SKINBkNhUXnzM5/YGv48WThJ7EI0l0sjBH+55pV+6EkDIFf1jm3UbP30u/KVxIOILJCD4sKdxV16CpgdxcYtY5tEoHEhUYK2wGJWV3OTo5qWWi/SG7nYNcOwJoi/V3S2mJf1wGNZmb3OIYc/OXpIG3Spc1pYXIN7a2JTzYytVf4rYZPNdxGgk0HYynhJQOsWUCj0AT2MC8052BzdGE/BsonH8dLUlXO57gqhaO1pJFucoPsFMoVHedNMnmrF6B1zVclPwsvmg518K7HKPXgfLYYae62avc7prUvd8jlcR3bJCFeFiludNzaX7966ecXPNZAIG7a3xUPniiWK76sVAsj9o6KNtAm+pPZskpqEH2ODUfNEGQqJrjBztPsM4TnWoEDg7uOdXpM+GIRXcLiY+yQNwb5QyAu6GjflzWAzDpy5BLYxGnQyDVl9cRmFLcF/9mVD9qdvN3AE7GeCu4Byj3nQXwIH5yB9WGiBMfS2QPBl7M/MPQjcCYK0sjtP9QnMfMlLpL/URK13YOKrdBJppruCuDnviwx31nt/RlnHOIL7yg2Kg6tJ4JhE/85bJsTglA1yppAvm3y1p1+qouAINHbr2b/3tBGpvGr7fvULQiBOt2CItzpHQtpt/m5K1qjxj9+jeLuDIBS6eAPGThZC3dvsesLWzeM6SKGn3ConnoJOwR3Zc7scaohncuxaL924FI4lbmvIiXHYMkcuG5zL/QAt 8aEPTsa1 QCKJ3XYoOhs8weQOFfQ6jjz/bhArHd9V2KIXdkQ+8dyInFAP25sU4MaF+F42Z0o+Wv4mYISSMgj0jYOx83SX3wt03i7lFQZDbroyGFkkP/8hWyrdu8XgrHR5KjxUiU7CKz4vwr9FNMPZVXQKjGpaR/2aEIGR749i5PffoDXMrI85KtviThYo+5rM81JZEtealhjlx3S/4/wZ0+tgcm2I2DYsNCA== 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 Thu, Aug 15, 2024 at 04:46:04PM +0100, Mark Brown wrote: > On Thu, Aug 15, 2024 at 04:33:25PM +0100, Dave Martin wrote: > > On Thu, Aug 15, 2024 at 04:05:32PM +0100, Mark Brown wrote: > > > > The expectation (at least for arm64) is that the main program will only > > > have shadow stacks if everything says it can support them. If the > > > dynamic linker turns them on during startup prior to parsing the main > > > executables this means that it should turn them off before actually > > > starting the executable, taking care to consider any locking of features. > > > Hmm, so we really do get a clear "enable shadow stack" call to the > > kernel, which we can reasonaly expect won't happen for ancient software? > > Yes, userspace always has to explicitly enable the GCS. > > > If so, I think dumping the GCS state in the sigframe could be made > > conditional on that without problems (?) > > It is - we only allocate the sigframe if the task has GCS enabled. OK, makes sense. > > > > Related question: does shadow stack work with ucontext-based coroutines? > > > > Per-context stacks need to be allocated by the program for that. > > > > Yes, ucontext based coroutines are the sort of thing I meant when I was > > > talking about returning to a different context? > > > Ah, right. Doing this asynchronously on the back of a signal (instead > > of doing a sigreturn) is the bad thing. setcontext() officially > > doesn't work for this any more, and doing it by hacking or rebuilding > > the sigframe is extremely hairy and probably a terrible idea for the > > reasons I gave. > > I see. I tend to view this as more adventurous than I personally would > be when writing userspace code but equally I don't see a need to > actively break things. There's no *requirement* to use libc... > > > So, overall I think making ucontext coroutines with with GCS is purely > > a libc matter that is "interesting" here, but we don't need to worry > > about. > > Yes, it's not our problem so long as we don't get in the way somehow. Sure. "Hairy and probably a terrible idea" is not the same as "impossible", but you need to know what you're doing and you get exposed to all sorts of portability challenges. There's a limit to how much we should attempt to smooth over all that. Anyway, I think what the GCS patches are doing looks reasonable. Cheers ---Dave