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 E6572C3DA64 for ; Wed, 31 Jul 2024 10:39:42 +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=Nmkcaa1PzjBtRsISbUrh2dKQPY2g/ADVVFiymxHyfAQ=; b=iL+6MVKMNwu5KZ5cub6Kgolsvs 6gcL0vnJVlcYcJ5j+Hr8NuxUkrCQTZBLGUWBtNQIlfWJZonClYEOx7S+z3CX5zOvLkTSFJ9ylCJ+G DcI4+Ik3mAxck6BOkfsU1qWnutLehYGgTRJ8x3OLwJtMklfwSt4Ijb9iS5WtK+K8xouBBftLG0skO /JvEoyn3ouTP2yiFEzD00MYwsZnnmb+CIACb66ivr5gaox4jbvB7yCngQFbEWMUwtJMf5cuHwVA5g Xr35eLZNpd0PnG9cRAQims8IePgWRg9NCatCnWg8OCq//bQboIpPcFtGRAP3zpTfPTJMJY18Q5iH3 wstZfJVw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZ6jz-00000000kZ2-0tOh; Wed, 31 Jul 2024 10:39:31 +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 1sZ6jW-00000000kVG-3Gom for linux-arm-kernel@lists.infradead.org; Wed, 31 Jul 2024 10:39:04 +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 C22B11007; Wed, 31 Jul 2024 03:39:27 -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 6833F3F5A1; Wed, 31 Jul 2024 03:39:01 -0700 (PDT) Date: Wed, 31 Jul 2024 11:38:55 +0100 From: Dave Martin To: Mark Brown Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Joey Gouly Subject: Re: [PATCH] arm64: signal: Update sigcontext reservations table Message-ID: References: <20240729144149.249096-1-Dave.Martin@arm.com> <8f867f53-df7e-43c4-9c99-c43a4111d5a1@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240731_033902_924021_BC2AA754 X-CRM114-Status: GOOD ( 37.67 ) 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 Tue, Jul 30, 2024 at 05:00:17PM +0100, Mark Brown wrote: > On Tue, Jul 30, 2024 at 04:07:22PM +0100, Dave Martin wrote: > > On Tue, Jul 30, 2024 at 02:22:47PM +0100, Mark Brown wrote: > > > > Well, it only requires thought if you do something that pays attention > > > to the signal frame layout - an awful lot of programs simply don't look > > > at the frame and so don't care. There are things like userspace threads > > > which are particularly likely to be impacted but there's also a lot of > > > code that just handles a signal and returns without ever looking at the > > > frame. > > > A program can't not pay attention to the sigframe _size_, i.e., even if > > you ignore the sigcontext, you still have to have allocated your stack > > big enough for it. > > > That's the fundamental issue here. > > A good percentage of programs manage to just use a default rather then > ever explicitly specifying or configuring anything themselves - C > programs will default to RLIMIT_STACK IIRC which is system configured > and generally set rather high. It's true that anything that is > explicitly configuring stack sizes needs to worry about having enough > stack space for a signal frame on top of whatever else it's doing > (including anything limiting things system wide) but I'd be a bit > surprised if it were the common case that things were actually paying > attention. That's all true, but even programs that don't explicity work out stack sizes may be using implicit knowledge, beacuse the developers may have simple bumped up stack sizes. Note, RLIMIT_STACK only applies the initial stack of the main thread. Processes with threads might have many stacks, as might processes with fibers/coroutines (allocated any old how, and often with no reference to RLIMIT_STACK). The aim here is to minimise surprises for code that made reasonable assumptions at the time it was written, rather than to ensure that every ancient binary that ever worked by accident still works, no matter what crazy nonportable shenanigans it gets up to. > > > > > Ideally, the toolchain would mark binaries with the features they are > > > > compatible with, and try to load only compatible objects into the same > > > > process. The ELF properties (as used for BTI etc.) provide a generic > > > > mechanism for this, but maybe we need to start pushing for labelling > > > > for other properties too. The "can it trigger an oversized sigframe" > > > > property of an arch feature won't be obvious to the toolchain folks. > > > > Hrm. I can see this being fun with working out how the various > > > extensions compose with each other and how to turn things that the > > > toolchain usually wouldn't be aware of on. > > > That's why I went for a simplified model: > > > If a program exercises no opt-ins at all, then the sigframe must fit in > > MINSIGSTKSZ bytes. > > > If the program exercises any opt-in at all, the sigframe is not > > guaranteed to fit in MINSIGSTKSZ bytes. It's then the program's > > responsibility to pay attention to the real worst-case size advertised > > in AT_MINSIGSTKSZ in the auxv. > > > As noted in the references, programs built against glibc-2.34 or later > > with -D_GNU_SOURCE (or -D_DYNAMIC_STACK_SIZE_SOURCE) will actually be > > using values based on the AT_MINSIGSTKSZ parameter rather than the old > > constant; uses of MINSIGSTKSZ and SIGSTKSZ that require it to be > > compile-time constant won't compile. > > > The idea of the table in sigcontext.h was to help us track where opt- > > ins are needed, and what opt-in conditions exist. This maybe wasn't as > > clear as it could have been. > > I think some of it is the strength of the opt ins being considered. Sorry, what do you mean here? Cheers ---Dave