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 1FEE0D3E196 for ; Mon, 21 Oct 2024 17:26:19 +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=juG7JTzJ1I5gc95HmcX8jHaRQb1BYj77gkn4rawA1EY=; b=jW3qrVbRvnIPIplj2Dtk3fnK4o EeyPXGdEGriCocLcr42I1QA+01UHEL1zyw6OqmE+0GEa7lZDwUApSuwcyujoPi0DUkbfAnudyR8EZ rgCjHrQ/hy0iEKhb3s0cJNIABJwuu0kLnKNwVesWChOWngGKbBfskU6s9tq2t1gHTQvmgIYz//Y10 whXYUbsTkIDv83dsOkpSvLkohEFfFHP+9QPiS9Hmy2ZOSt+dLFe70QWnhCFr26zUhaDkiQaqfs/EU ZEjRksrm8oWNtA649uFx52IeAMVunU/5qgYxuAd3JkTT3eynwwfymc87TLtoWZca/Vr16kdI7Gkdf 5zkiE5xA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t2wAR-000000087O7-10KF; Mon, 21 Oct 2024 17:26:07 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t2w4S-000000086NR-19WG for linux-arm-kernel@bombadil.infradead.org; Mon, 21 Oct 2024 17:19:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=juG7JTzJ1I5gc95HmcX8jHaRQb1BYj77gkn4rawA1EY=; b=pzKskXdgmQduQHv2DQpRnlaKWe s85DfYORp4EAiQsEVcoPdX2O8S76PSdavWBirBUnPTFpCAD+PyMPeZYtzPrRNhUbg2VAxAvLFE4g9 sUtT0s/3IfvajPlkKI8/Hh0oqTGEVdP9tvJ8JMaYf0xN2MC7ALTMwppKSD1y8biNbPYejqW0WcFI6 AMsCrwVbnjDp3/8Rw70TikRShnn0Hy8o8ONauoJEG+tLvWjiNLlL0bAzY3uB4oBrdQHLgcIfh/Xkm TP57MyIBRPZomDGnmZy4w62z+umNH6qY69jS3tz3V0j+QqOsAcAf8pJS7p48JjkDG1gz4x9vuq8l1 1NQzXTUQ==; Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by desiato.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t2w4N-000000081eQ-2jqD for linux-arm-kernel@lists.infradead.org; Mon, 21 Oct 2024 17:19:54 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 28CD6A4354B; Mon, 21 Oct 2024 17:19:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB037C4CEC3; Mon, 21 Oct 2024 17:19:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729531184; bh=tiWcGz/xjhXfgcJ1cihsOzYbVkw2f48yxSQeFEQ/jVs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IXgyR2wXk4rzx1jsLFIZEMqnheGakQpNqOYPBze8diTWLkxvdYgmXWeCvY0yeIBNO aGFnMO+zrr8dTcV6FsfTd4kFaERJFsHYrAwUKzsniVu881+AGB64r/QsiSvALCdT0m 4YOB0RSDzb+RL9GDhMzWRzXm215DhX5tsLD19SZDt1g00LKaQMBK36UKO6ZAXku9g/ 3vLy32jsnXCzIG8oktHgFhgkPPGMzbts/vTvVwl1VSRXqH78/ANkUggn9RL4Artcy7 5DryMcQROcxMTjwvZqKzGKKiBFXlG5CNfaOAP1yjRaFqOzx2mgpACGHvDUuLLizjzb SHKEK/tCSDRRw== Date: Mon, 21 Oct 2024 18:19:38 +0100 From: Will Deacon To: Catalin Marinas Cc: Dave Martin , Kevin Brodsky , linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, anshuman.khandual@arm.com, aruna.ramakrishna@oracle.com, broonie@kernel.org, dave.hansen@linux.intel.com, jeffxu@chromium.org, joey.gouly@arm.com, shuah@kernel.org, linux-kselftest@vger.kernel.org, x86@kernel.org, pierre.langlois@arm.com Subject: Re: [PATCH 0/5] Improve arm64 pkeys handling in signal delivery Message-ID: <20241021171937.GA26179@willie-the-truck> References: <20241017133909.3837547-1-kevin.brodsky@arm.com> <627c1297-8151-43d1-b46b-a962301b18fa@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241021_181952_023288_4F4B998E X-CRM114-Status: GOOD ( 41.15 ) 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, Oct 21, 2024 at 04:30:04PM +0100, Catalin Marinas wrote: > On Mon, Oct 21, 2024 at 02:31:08PM +0100, Dave P Martin wrote: > > > > On Thu, Oct 17, 2024 at 02:39:04PM +0100, Kevin Brodsky wrote: > > > >> This series is a follow-up to Joey's Permission Overlay Extension (POE) > > > >> series [1] that recently landed on mainline. The goal is to improve the > > > >> way we handle the register that governs which pkeys/POIndex are > > > >> accessible (POR_EL0) during signal delivery. As things stand, we may > > > >> unexpectedly fail to write the signal frame on the stack because POR_EL0 > > > >> is not reset before the uaccess operations. See patch 3 for more details > > > >> and the main changes this series brings. > > > >> > > > >> A similar series landed recently for x86/MPK [2]; the present series > > > >> aims at aligning arm64 with x86. Worth noting: once the signal frame is > > > >> written, POR_EL0 is still set to POR_EL0_INIT, granting access to pkey 0 > > > >> only. This means that a program that sets up an alternate signal stack > > > >> with a non-zero pkey will need some assembly trampoline to set POR_EL0 > > > >> before invoking the real signal handler, as discussed here [3]. > [...] > > Memory with a non-zero pkey cannot be used 100% portably, period, and > > having non-RW(X) permissions on pkey 0 at any time is also not > > portable, period. So I'm not sure that having libc magically guess > > what userspace's pkeys policy is supposed to be based on racily digging > > metadata out of /proc/self/maps or a cache of it etc. would be such a > > good idea. > > I agree that changing RWX overlay permission for pkey 0 to anything else > is a really bad idea. We can't prevent it but we shouldn't actively try > to work around it in the kernel either. With the current signal ABI, I > don't think we should support anything other than pkey 0 for the stack. > Since the user shouldn't change the pkey 0 RWX overlay permission > anyway, I don't think we should reset POR_EL0 _prior_ to writing the > signal frame. The best we can do is document it somewhere. > > So on patch 3 I'd only ensure that we have POR_EL0_INIT when invoking > the signal handler and not when performing the uaccess. If the uaccess > fails, we'd get a fatal SIGSEGV. The user may have got it already if it > made the stack read-only. Hmm, but based on what Kevin's saying, this would mean actively choosing a different ABI than what x86 is trying to get to. > Currently the primary use of pkeys is for W^X and signal stacks > shouldn't fall into this category. If we ever have a strong case for > non-zero pkeys on the signal stack, we'll need to look into some new > ABI. I'm not sure about SS_* flags though, I think the signal POR_EL0 > should be associated with the sigaction rather than the stack (the > latter would just be mapped by the user with the right pkey, the kernel > doesn't need to know which, only what POR_EL0 is needed by the handler). > > Until such case turns up, I'd not put any effort into ABI improvements. Kevin -- do you know what prompted x86 to want the pkey to be reset early in signal delivery? Perhaps such a use-case already exists. > I can think of some light compartmentalisation where we have a pkey > that's "privileged" and all threads have a POR_EL0 that prevents access > to that pkey. The signal handler would have more permissive rights to > that privileged pkey. I'd not proactively add support for this though. I'd not proactively diverge from other architectures, either :p Will