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 938B5C3DA7E for ; Tue, 30 Jul 2024 12:52:07 +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=a/vn/UnWP09bDUYgRabXkmDnCjJahHh97G0BrL5E4jQ=; b=spngyFZFlDCfk2xuSrbNssvlvz hTc8cUE9jwHPVlA7o0XV38VgB35ZDerkWa38fEmWVljN9sOy0nClcETKArSBUt66VDIuVl5ImJVvC EBbmR0wYOCSQg7oTQ1u/b9iW5bDEB26tIiVDDUyKtHYwqIeeFDuCMqW8zWBEPDoO7VaKKBv8QxPFS ifyzFSKSd0lNmRJmYZaOuGJMBIaPoSv9I9Wv8fDUpow0znMjdI+LCFv54egBK5YyyNTKgPbT0zFW/ iWcoQsbu1v5lp4xxKO5lrhzZ1/EXswT1FYVXCZM26Jw/DBUoYV/u1M2pZJrf3xOcR5TGxjiQsOuYH SQAnnFNw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYmKa-0000000FAVK-1gHk; Tue, 30 Jul 2024 12:51:56 +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 1sYmK8-0000000FAO6-1UjR for linux-arm-kernel@lists.infradead.org; Tue, 30 Jul 2024 12:51:30 +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 BA4D91007; Tue, 30 Jul 2024 05:51: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 3A3DB3F5A1; Tue, 30 Jul 2024 05:51:25 -0700 (PDT) Date: Tue, 30 Jul 2024 13:51: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_055128_519937_C9AF0EAF X-CRM114-Status: GOOD ( 37.31 ) 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 Hi, On Mon, Jul 29, 2024 at 06:01:02PM +0100, Mark Brown wrote: > On Mon, Jul 29, 2024 at 04:51:27PM +0100, Dave Martin wrote: > > On Mon, Jul 29, 2024 at 03:53:12PM +0100, Mark Brown wrote: > > > > 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. > > > 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. > > I think anything that goes and fiddles with the vector length > dynamically from a library is sufficiently adventurous that it's kind of > out of scope here. Yes. There are ways to do it (mostly) safely, but it's fiddly, and it seemed too hard to make promises that would be useful to general purpose userspace code. > > 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. > > 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. How userspace decides whether to opt in is outside the scope of the kernel, so the original SVE design at least tried to make things safe by default, using the sve_default_vector_length clamp. 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. In the future, distros might consider the codebase fully "large sigframe aware", and increase sve_default_vector_length so that all processes are opted in without having to do anything; that amounts to a system-level opt-in. Similarly for SME. 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. If some feature needs a prctl() to enable it when first upstreamed, then it's probably best to leave it up to ld.so and the libc startup code to decide whether and when to call it. Even if the kernel some day can do this automatically based on ELF properties or something, we'd still need to be backwards compatible. If the "turn on" call requires parameters, then something in userspace would need to use it explicitly anyway. Not sure whether any of this simplifies the discussion... Cheers ---Dave