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 42AF8C3DA70 for ; Tue, 30 Jul 2024 15:08:36 +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=uVpLkcqE/O5YyiRni3GS9MeP4aqfJkvWlGemhanCQUM=; b=eg/9ukUzc0EuzIRcsQhpLP10ES LGhSHGlNMDxThLsLfrdNOJINnhNrGth7tGXAr62Ig+Twr49ds8XA+IMWMCOCQrFIkRvFjIzJX02Xl 6Ct4lEduYiz2Oi02YOQWTYSQb+HwTTE6hyZ9L6DhPkLZbApKv3FXzaoAqCyxNzMYf+XA1FfNj5QOs rgo3Bo1/hKo8Pagpxh1lFA3DZnn1KZcPcllL08KwioFzEYkjMFj5ASfasoyXyeDlKD3tkjI6nN2AB 858XPkF4vCjG8OGMoXSboLHTfUo9Qh+WXQyqlKsp7TCY3z3EfRbSJFhiU1/L8MocK1a7vuBn+FhvS 8PTLjBzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYoSd-0000000FagS-1hb5; Tue, 30 Jul 2024 15:08:23 +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 1sYoRq-0000000FaOS-1DMv for linux-arm-kernel@lists.infradead.org; Tue, 30 Jul 2024 15:07:35 +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 5C8901007; Tue, 30 Jul 2024 08:07:51 -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 068333F5A1; Tue, 30 Jul 2024 08:07:24 -0700 (PDT) Date: Tue, 30 Jul 2024 16:07:22 +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-20240730_080734_440746_4216B3F6 X-CRM114-Status: GOOD ( 31.16 ) 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 02:22:47PM +0100, Mark Brown wrote: > On Tue, Jul 30, 2024 at 01:51:22PM +0100, Dave Martin wrote: > > On Mon, Jul 29, 2024 at 06:01:02PM +0100, Mark Brown wrote: > > > > Hrm, indeed. I think while you're at clarifying this it'd be good to > > > clarify what we're thinking of as opting in - is it userspace as a whole > > > we're thinking of or is it a specific dynamically linked binary? > > > There's also things like the dynamic linker and code generation options > > > in the compiler to worry about here... > > > I think that the opt-in has to be per running process. > > Yes, I tend to agree. > > > Since making the opt-in decision correctly requires some effort, I > > expected that most programs just won't bother and won't opt in unless > > they actually need a given feature in order to work at all. > > 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. > > 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. Cheers ---Dave