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 81F1DD1CDD9 for ; Tue, 22 Oct 2024 10:47:27 +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=FA8/LiP3fphHTFK1+JSMAgEJJxKA8izGscyYUwIcfxU=; b=ZfYtAtWDKBuCS/B3pOZe5G5uOK ALPIqcrs1++tDhKGSyxiz/WZbi8W1wBxi8KYPLrehQ4+kNTsBe+UNWjQySWF5oKNvPg0mtJPRtoGz GPZ21KdPF5EM1mT2u6fRsPZxXs2zHxIw9iBqQ0AFN8hu/P8gZyOEyJdD9Np5uolOQR8/TMhrpWhJ8 B0dfjNsa3ALeGOlsidcjO7MO/e/DooD6brT0Dqb75zA1xbhHnHeAyqT0JvkrTh3dB3XOMp07gK4rV RGFHypARRB4bTs1fbJn18ho8T8SqIk0wMyTfU8hKTRoiuoDWp3grsgjqPZw2x8L39VMb9p939nJ6z 7eqTnsWg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t3CPy-0000000AZnA-196d; Tue, 22 Oct 2024 10:47:14 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t3COR-0000000AZUY-2iLA for linux-arm-kernel@lists.infradead.org; Tue, 22 Oct 2024 10:45:41 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id EB061A41B5B; Tue, 22 Oct 2024 10:45:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40E04C4CEE4; Tue, 22 Oct 2024 10:45:35 +0000 (UTC) Date: Tue, 22 Oct 2024 11:45:32 +0100 From: Catalin Marinas To: Will Deacon 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: References: <20241017133909.3837547-1-kevin.brodsky@arm.com> <627c1297-8151-43d1-b46b-a962301b18fa@arm.com> <20241021171937.GA26179@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241021171937.GA26179@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241022_034539_816025_BEAFA5EB X-CRM114-Status: GOOD ( 44.59 ) 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 06:19:38PM +0100, Will Deacon wrote: > 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. I was more thinking of not relaxing the ABI further at this point in the rc cycle rather than completely diverging (x86 did relax the ABI subsequently to handle non-zero pkey sigaltstack). > > 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. Given the email from Pierre with Chrome potentially using a sigaltstack with a non-zero pkey, Kevin's patches (and the x86 changes) make more sense. The question is whether we do this as a fix now or we leave the relaxation for a subsequent kernel release. I guess we could squeeze it now if we agree on the implementation. -- Catalin