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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBC19C52D7D for ; Thu, 15 Aug 2024 13:18:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 647366B00E5; Thu, 15 Aug 2024 09:18:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F6C96B00E6; Thu, 15 Aug 2024 09:18:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BE216B00E7; Thu, 15 Aug 2024 09:18:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2E8E56B00E5 for ; Thu, 15 Aug 2024 09:18:28 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D29D2141554 for ; Thu, 15 Aug 2024 13:18:27 +0000 (UTC) X-FDA: 82454533854.05.F50E825 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf27.hostedemail.com (Postfix) with ESMTP id E20E640009 for ; Thu, 15 Aug 2024 13:18:25 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of joey.gouly@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=joey.gouly@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723727833; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qFggLUHmS2ocA6NISGJaggipo/K9a4Q5ECqmqwr2Mik=; b=dFgKDAa0oWPMRtTuc7nC2M2E6kVhcr92dSQiWdmqgVc5gtJHR4pNGsUxmeZLS9EvEOCz5G tTABG1hHAGYjfJ1Dvkkk4V+WqIDhnh8yG9yfWrRO+sxCvNB79bctt+mKcM5nYPqdOFTWey MjP/TMdNHUyCL91o3aC5saSB0tsbI+M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723727833; a=rsa-sha256; cv=none; b=nv1VmA/9kVe12TKW0CSGsF7aRy7jKufOzHi+3LekkZSvKLLlln9/iQkPwDU+gtgrOMRnJk Z9yxuRMZxIRS1FmyVwOf4If1MYBkMWTdfQ9lPYbNGIhrQyhjuy4pKcDYJvGa/bSnuG0jEz ZCrwX7H0umm9qYc7ZeDFxOVSDh9xKzo= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of joey.gouly@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=joey.gouly@arm.com; dmarc=pass (policy=none) header.from=arm.com 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 C896914BF; Thu, 15 Aug 2024 06:18:50 -0700 (PDT) Received: from e124191.cambridge.arm.com (e124191.cambridge.arm.com [10.1.197.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 52C343F6A8; Thu, 15 Aug 2024 06:18:21 -0700 (PDT) Date: Thu, 15 Aug 2024 14:18:15 +0100 From: Joey Gouly To: Catalin Marinas Cc: Dave Martin , linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, aneesh.kumar@kernel.org, aneesh.kumar@linux.ibm.com, bp@alien8.de, broonie@kernel.org, christophe.leroy@csgroup.eu, dave.hansen@linux.intel.com, hpa@zytor.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, maz@kernel.org, mingo@redhat.com, mpe@ellerman.id.au, naveen.n.rao@linux.ibm.com, npiggin@gmail.com, oliver.upton@linux.dev, shuah@kernel.org, szabolcs.nagy@arm.com, tglx@linutronix.de, will@kernel.org, x86@kernel.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v4 18/29] arm64: add POE signal support Message-ID: <20240815131815.GA3657684@e124191.cambridge.arm.com> References: <20240503130147.1154804-1-joey.gouly@arm.com> <20240503130147.1154804-19-joey.gouly@arm.com> <20240801155441.GB841837@e124191.cambridge.arm.com> <20240806103532.GA1986436@e124191.cambridge.arm.com> <20240806143103.GB2017741@e124191.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: xr8cse6m7gy9etttmmh8boymeti859qw X-Rspamd-Queue-Id: E20E640009 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1723727905-316301 X-HE-Meta: U2FsdGVkX18CDf+ow94oEsMc7522ezlb/aQ8Oj5xO5Q5rnc85pohPoQWfdWgs7ZVDlRjg+IblG0/R3XYxEDBy6htxErpPQp1qIBrfNnMQTAe1IzSZB7scSGxfwVuNcdnZuSrHjR00WKAWRK9VC3vQo9E7UwQ8y5zw8G60jSSLAEWFCzLrwC2/ae7hwmevCNKD+y+OrKbff3xN3K4aIqBZaXUpHHuk5IuTjlT7Cukg3jWmoZEvgkE5Llw4VfvKzS+5R4b2o2j9uwBKQ08m7Ywh0zoeI5Dkf/UjVBbhNxYJlUtpG59hw35T4GW/Y/ourVhvr7OB7IP7+tl3kC1oczb5mhK4ZPLI9zNEouKPTFIGvyQxI6syMU8AK//cgKEztP+Np5h0lifRbfET6s4hjT76a45Tyt8IUlvTRep72H/zEie/QuYdsypiH9nU9IuoTdT6UOTQWwP5WRURUq7DkxZxLMdv5n5fE2z9QZdLNUl3ZH+0Lx7vLnBkr3tYunRq1gkP7U1g7hFOa35VyfC9/KFqEmuo82sc2BHGTLFn5WSRwf4nJCD7hrk1vn0h/fVrhaMxh6dKjtV354tcVAqsy6VUzpzQRaQaQ7/8GF/Q7JlbraHvZq5/m52TMVBR+CcyFRgP88eiCG46/y7XmnYNjveES6z9PRy7XScR5cIyX6GRYItFPk+mB/E5dUV3MIl4AW+BVZGG+fM9If94w7if/jYXZs64dxhLChMZ55RAEFFlTGZipslFraDye64M35GqsU/oitDsXMN9QMqlEikmiVMMdpK4vM3y95UaCJU638ovN+Pk7y14h0Iu2Ke5q0EL9iVn2CfYYlvugm/3a2LsUC19TZA4flNnKl4iYptThj5yO8a/tzM7m/EFoFOvOVZKRr1B75oKZJNjIVPGHxNUHtZair5DQwnM5vzuOQBzJKddnZn3Pb18Awi87EOCivcR3upx1dPeiFp9tPNxUC4E/A gtX4bs1B 1OoN1V5wmgTt8sy2g0zojaMHCeOZ3cIVOdDwomqHYP4Sn8NSd41v1IzCaE7Y/u7vAG42PcwyG2+KAu/sFjbZXVAlKar6uizVcRfql8P+5g2kdgFmvK+JB2vhFIgioIifXNTmVUszyOAZQcDAw5PG0Ltjrew== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Catalin, On Wed, Aug 14, 2024 at 04:03:47PM +0100, Catalin Marinas wrote: > Hi Joey, > > On Tue, Aug 06, 2024 at 03:31:03PM +0100, Joey Gouly wrote: > > diff --git arch/arm64/kernel/signal.c arch/arm64/kernel/signal.c > > index 561986947530..ca7d4e0be275 100644 > > --- arch/arm64/kernel/signal.c > > +++ arch/arm64/kernel/signal.c > > @@ -1024,7 +1025,10 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user, > > return err; > > } > > > > - if (system_supports_poe()) { > > + if (system_supports_poe() && > > + (add_all || > > + mm_pkey_allocation_map(current->mm) != 0x1 || > > + read_sysreg_s(SYS_POR_EL0) != POR_EL0_INIT)) { > > err = sigframe_alloc(user, &user->poe_offset, > > sizeof(struct poe_context)); > > if (err) > > > > > > That is, we only save the POR_EL0 value if any pkeys have been allocated (other > > than pkey 0) *or* if POR_EL0 is a non-default value. > > I had a chat with Dave as well on this and, in principle, we don't want > to add stuff to the signal frame unnecessarily, especially for old > binaries that have no clue of pkeys. OTOH, it looks like too complicated > for just 16 bytes. Also POR_EL0 all RWX is a valid combination, I don't > think we should exclude it. > > If no pkey has been allocated, I guess we could skip this and it also > matches the x86 description of the PKRU being guaranteed to be preserved > only for the allocated keys. Do we reserve pkey 0 for arm64? I thought > that's only an x86 thing to emulate execute-only mappings. To make it less complicated, I could drop the POR_EL0 check and just do: - if (system_supports_poe()) { + if (system_supports_poe() && + (add_all || + mm_pkey_allocation_map(current->mm) != 0x1) { This wouldn't preserve the value of POR_EL0 if no pkeys had been allocated, but that is fine, as you said / the man pages say. We don't preserve pkey 0, but it is the default for mappings and defaults to RWX. So changing it probably will lead to unexpected things. > > Another corner case would be the signal handler doing a pkey_alloc() and > willing to populate POR_EL0 on sigreturn. It will have to find room in > the signal handler, though I don't think that's a problem. pkey_alloc() doesn't appear in the signal safety man page, but that might just be an omission due to permission keys being newer, than actually saying pkey_alloc() can't be used. If POR_EL0 isn't in the sig context, I think the signal handler could just write the POR_EL0 system register directly? The kernel wouldn't restore POR_EL0 in that case, so the value set in the signal handler would just be preserved. The reason that trying to preserve the value of POR_EL0 without any pkeys allocated (like in the patch in my previous e-mail had) doesn't really make sense, is that when you do pkey_alloc() you have to pass an initial value for the pkey, so that will overwite what you may have manually written into POR_EL0. Also you can't pass an unallocated pkey value to pkey_mprotect(). That's a lot of words to say, or ask, do you agree with the approach of only saving POR_EL0 in the signal frame if num_allocated_pkeys() > 1? Thanks, Joey