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 A5E36D374AE for ; Thu, 17 Oct 2024 15:59:17 +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=kEGgIqJ2ON3sJDJQYUPf/qdww5LQcaeIWjV3NZIGHoU=; b=la19Kt2BHI5IZV1oSGOl0Nm8NJ uiD2hV5goGwSz/SaN/9XAJKjP9Bw0icopHq1B1hhQVG3V1BBLxwCIjzW3MFMDFQwmB+20mA0nA1y/ WX69DxaueE87dBOPLE5QC7I4FN7x0dUjtZEGvxlaZxxk79KcRHaZcF9PZqPXzypFNtkqgiR2EhKUQ 8hJhFaQNKTzW/T50PA09gl7RxsYTXE44Km4YpWQza4DOHyDqGM/Axd3vDt6IC3Mn5uLKm/KkKXfvW xbWfERkA5+0bBKueQdWpf/aiC/vh2sy52eQvg4CKfXNZbZIpaCZQt+wVIzYXpEICU6np3i8rNj+DY sY9ZNGfA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1Su3-0000000FO1s-0Ya7; Thu, 17 Oct 2024 15:59:07 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1SkP-0000000FMF6-1Ru9 for linux-arm-kernel@lists.infradead.org; Thu, 17 Oct 2024 15:49:10 +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 4998DFEC; Thu, 17 Oct 2024 08:49:36 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.51]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7F94F3F528; Thu, 17 Oct 2024 08:49:04 -0700 (PDT) Date: Thu, 17 Oct 2024 16:48:53 +0100 From: Dave Martin To: Kevin Brodsky Cc: linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, anshuman.khandual@arm.com, aruna.ramakrishna@oracle.com, broonie@kernel.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, jeffxu@chromium.org, joey.gouly@arm.com, shuah@kernel.org, will@kernel.org, linux-kselftest@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 0/5] Improve arm64 pkeys handling in signal delivery Message-ID: References: <20241017133909.3837547-1-kevin.brodsky@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241017133909.3837547-1-kevin.brodsky@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241017_084909_446388_4B47F954 X-CRM114-Status: GOOD ( 15.58 ) 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 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]. This feels a bit bogus (though it's anyway orthogonal to this series). Really, we want some way for userspace to tell the kernel what permissions to use for the alternate signal stack and signal handlers using it, and then honour that request consistently (just as we try to do for the main stack today). ss_flags is mostly unused... I wonder whether we could add something in there? Or add a sigaltstack2()? [...] Cheers ---Dave