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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 054B9C3DA7F for ; Thu, 15 Aug 2024 16:41:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=J/vungWYPE46FHbRiXVMLqjflva1DGRgLIRC0krccZk=; b=Onv5AGaomPIRtnKYxiY++aKXYZ ul7HNluiStreWkkAucHO8hm37CrLmCs8WYoQFZJJwFr/hUiKOm6rS6KArZ4tsfY1oLLbR/RoJe5Uf DcGhXKGptn5y/hJUpVOtrYwMQjit6KavRiS9cJqZPMM81NI/V/u5XoeGCjEOUHqobYWQd32gidSmc tz4jifJRzoJEhOB17QXg7rq+3P7YHZatxKzaYVEPiRjVyIPDrdJkgnSqNgKXgOc0iClZU8eu5EKdk zgP678RnkyL4I9MEDMf3+FYEj5uf78RRzb+2akffrytuaVttgWJnAgeQT6T0ApsS0k0wO5rFmuxD6 GWJR9YiA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sedXN-0000000AXsq-3P8u; Thu, 15 Aug 2024 16:41:21 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sedWf-0000000AXjR-1B38; Thu, 15 Aug 2024 16:40:43 +0000 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240815_094037_430235_41C023E8 X-CRM114-Status: GOOD ( 30.39 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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