linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Kevin Brodsky <kevin.brodsky@arm.com>
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
Date: Thu, 17 Oct 2024 16:48:53 +0100	[thread overview]
Message-ID: <ZxEx5aXPX2mHngoB@e133380.arm.com> (raw)
In-Reply-To: <20241017133909.3837547-1-kevin.brodsky@arm.com>

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


  parent reply	other threads:[~2024-10-17 15:59 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-17 13:39 [PATCH 0/5] Improve arm64 pkeys handling in signal delivery Kevin Brodsky
2024-10-17 13:39 ` [PATCH 1/5] arm64: signal: Remove unused macro Kevin Brodsky
2024-10-17 15:49   ` Dave Martin
2024-10-21 10:05     ` Kevin Brodsky
2024-10-21 13:44       ` Dave Martin
2024-10-21 13:01   ` Catalin Marinas
2024-10-17 13:39 ` [PATCH 2/5] arm64: signal: Remove unnecessary check when saving POE state Kevin Brodsky
2024-10-17 13:52   ` Mark Brown
2024-10-17 15:49   ` Dave Martin
2024-10-21 13:02   ` Catalin Marinas
2024-10-17 13:39 ` [PATCH 3/5] arm64: signal: Improve POR_EL0 handling to avoid uaccess failures Kevin Brodsky
2024-10-17 15:53   ` Dave Martin
2024-10-21 10:06     ` Kevin Brodsky
2024-10-21 13:43       ` Dave Martin
2024-10-22 12:34         ` Kevin Brodsky
2024-10-22 12:38           ` Dave Martin
2024-10-21 14:38       ` Dave Martin
2024-10-17 13:39 ` [PATCH 4/5] selftests/mm: Use generic pkey register manipulation Kevin Brodsky
2024-10-17 13:39 ` [PATCH 5/5] selftests/mm: Enable pkey_sighandler_tests on arm64 Kevin Brodsky
2024-10-17 15:48 ` Dave Martin [this message]
2024-10-21 10:06   ` [PATCH 0/5] Improve arm64 pkeys handling in signal delivery Kevin Brodsky
2024-10-21 13:31     ` Dave Martin
2024-10-21 15:30       ` Catalin Marinas
2024-10-21 17:19         ` Will Deacon
2024-10-22 10:45           ` Catalin Marinas
2024-10-22  9:31       ` Pierre Langlois
2024-10-22 10:40         ` Stephen Röttger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZxEx5aXPX2mHngoB@e133380.arm.com \
    --to=dave.martin@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=aruna.ramakrishna@oracle.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jeffxu@chromium.org \
    --cc=joey.gouly@arm.com \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).