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 AA746C3DA4A for ; Mon, 29 Jul 2024 15:52:11 +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=6TsrqbI9qAJZDfl3kP1FY/S+ccSkHkT4M0D2DRtygo4=; b=k+1XioEzEWbOCaEN9Mreu1OvBg TWjOjEScLC2XYYc6St3iRxSWMbSBKbf2dbSoxw2Z+Gvwi1bPRylxDvamrtYhAUCrzwi3hmo4X+I0H 44KXRv/v8gIxGyiH7w2LX/Q8yXttK0wgVKojx+LAgZ5cMfXA3i9XsBszksiuQt8HQTyPN8REDJHSF k59+7nM7lU7qEr16CbFgCmWmGIVfVu4/lS3KIYYqH9GH1r2s0uR9el06I5FpDfU6I/RYvhh17D7Wj 8vec/jXXWPjG2RX0VzlBIG1Saa6t+XA4jVhRqo9iCcWKtiftRkOMvjObDUttqmweZ3QaPiu7AfH7i 4lrYpLbg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYSfH-0000000ButZ-2pGB; Mon, 29 Jul 2024 15:51:59 +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 1sYSeq-0000000BuoC-2mx9 for linux-arm-kernel@lists.infradead.org; Mon, 29 Jul 2024 15:51:34 +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 AAF9C1007; Mon, 29 Jul 2024 08:51:56 -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 265673F766; Mon, 29 Jul 2024 08:51:30 -0700 (PDT) Date: Mon, 29 Jul 2024 16:51:27 +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: <8f867f53-df7e-43c4-9c99-c43a4111d5a1@sirena.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240729_085132_765609_4E0CD5F0 X-CRM114-Status: GOOD ( 18.91 ) 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 Mon, Jul 29, 2024 at 03:53:12PM +0100, Mark Brown wrote: > On Mon, Jul 29, 2024 at 03:41:49PM +0100, Dave Martin wrote: > > > If Mark in particular can double-check the SME impact, that would be > > appreciated. > > ... > > > Additional SME note: since userspace can freely switch in and out of > > streaming SVE mode and freely enable/disable ZA and ZT0, I'm assuming > > that none of sve_context, za_context and zt_context are mutually > > exclusive, but please shout if I have confused myself here. > > There's no mutual exclusion here, but since we only generate the data > payloads if userspace explicitly chooses to enter streaming mode or > enable ZA/ZT0 I would tend to class any VL dependent size there as opt > in and only include the base structs. I'm not clear what your thinking > is with specifying them for some vector lengths. OK The basic test would be: can non large-sigframe-aware program blow up if ld.so links it against a library that uses SME internally? There is no absolute guarantee here, but firstly well-behaved libraries either shouldn't mess with the vector length or should block signals around critical sections (or create worker threads that block all signals), and secondly a paranoid program could preempt the prctl() function to prevent the vector length being changed. There is no way to prevent SM/ZA twiddling though, IIUC. Within the AArch64 application programmer's model and PCS rules, user code should be able to do whatever it likes without worrying about breaking other code. So a program must be prepared to accept the largest possible SME sigframe, given the current streaming SME vector length. Ditto all other features that can be used without an explicit call to enable (or fatten) them. Cheers ---Dave