On Fri, Oct 25, 2024 at 05:34:24PM +0200, Kevin Brodsky wrote:
> On 25/10/2024 13:33, Dave Martin wrote:
> > On Fri, Oct 25, 2024 at 10:24:41AM +0200, Kevin Brodsky wrote:
> >>>>>>> @@ -907,6 +964,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
> >>>
On Fri, Oct 25, 2024 at 10:24:41AM +0200, Kevin Brodsky wrote:
> On 24/10/2024 18:19, Dave Martin wrote:
> > On Thu, Oct 24, 2024 at 04:42:10PM +0100, Catalin Marinas wrote:
> >> On Thu, Oct 24, 2024 at 04:55:48PM +0200, Kevin Brodsky wrote:
> >>> On 24/10/202
On Fri, Oct 25, 2024 at 10:24:41AM +0200, Kevin Brodsky wrote:
> On 24/10/2024 18:19, Dave Martin wrote:
> > On Thu, Oct 24, 2024 at 04:42:10PM +0100, Catalin Marinas wrote:
> >> On Thu, Oct 24, 2024 at 04:55:48PM +0200, Kevin Brodsky wrote:
> >>> On 24/10/202
On Thu, Oct 24, 2024 at 04:42:10PM +0100, Catalin Marinas wrote:
> On Thu, Oct 24, 2024 at 04:55:48PM +0200, Kevin Brodsky wrote:
> > On 24/10/2024 12:59, Catalin Marinas wrote:
> > > On Wed, Oct 23, 2024 at 04:05:09PM +0100, Kevin Brodsky wrote:
> > >> +/*
> > >> + * Save the unpriv access state i
Hi,
On Tue, Oct 22, 2024 at 02:34:09PM +0200, Kevin Brodsky wrote:
> On 21/10/2024 15:43, Dave Martin wrote:
> > On Mon, Oct 21, 2024 at 12:06:07PM +0200, Kevin Brodsky wrote:
> >> On 17/10/2024 17:53, Dave Martin wrote:
> >>> [...]
> >>>> +/*
> >
Hi,
Just in case the reply I thought I'd sent to this evaporated (or I
imagined it):
On Mon, Oct 21, 2024 at 12:06:07PM +0200, Kevin Brodsky wrote:
> On 17/10/2024 17:53, Dave Martin wrote:
> > [...]
> >> +/*
> >> + * Save the unpriv access state into ua_s
On Mon, Oct 21, 2024 at 12:05:30PM +0200, Kevin Brodsky wrote:
> On 17/10/2024 17:49, Dave Martin wrote:
> > On Thu, Oct 17, 2024 at 02:39:05PM +0100, Kevin Brodsky wrote:
> >> Commit 33f082614c34 ("arm64: signal: Allow expansion of the signal
> >> frame") in
On Mon, Oct 21, 2024 at 12:06:07PM +0200, Kevin Brodsky wrote:
> On 17/10/2024 17:53, Dave Martin wrote:
> > [...]
> >> +/*
> >> + * Save the unpriv access state into ua_state and reset it to disable any
> >> + * restrictions.
> >> + */
> >&
On Mon, Oct 21, 2024 at 12:06:25PM +0200, Kevin Brodsky wrote:
> On 17/10/2024 17:48, Dave 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]
On Thu, Oct 17, 2024 at 02:39:07PM +0100, Kevin Brodsky wrote:
> TL;DR: reset POR_EL0 to "allow all" before writing the signal frame,
> preventing spurious uaccess failures.
>
> When POE is supported, the POR_EL0 register constrains memory
> accesses based on the target page's POIndex (pkey). This
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)
set has been checked before saving POR_EL0; this
> is in line with other frame records (FPMR, TPIDR2).
>
> Signed-off-by: Kevin Brodsky
Reviewed-by: Dave Martin
> ---
> arch/arm64/kernel/signal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arc
ite stating it explicitly.)
> Signed-off-by: Kevin Brodsky
Weird. Maybe there are places where this could have been used, but I
guess we have managed fine without it.
Or possibly some unmerged version of the SVE patches used this but it
disappeared in refactoring.
Either way:
Reviewed-by: Da
On Tue, Oct 15, 2024 at 12:41:16PM +0100, Will Deacon wrote:
> On Tue, Oct 15, 2024 at 10:59:11AM +0100, Joey Gouly wrote:
> > On Mon, Oct 14, 2024 at 06:10:23PM +0100, Will Deacon wrote:
> > > Kevin, Joey,
> > >
> > > On Wed, Oct 09, 2024 at 03:43:01PM +0100, Will Deacon wrote:
> > > > On Tue, Se
On Tue, Sep 24, 2024 at 01:27:58PM +0200, Kevin Brodsky wrote:
> On 22/08/2024 17:11, Joey Gouly wrote:
> > @@ -1178,6 +1237,9 @@ static void setup_return(struct pt_regs *regs, struct
> > k_sigaction *ka,
> > sme_smstop();
> > }
> >
> > + if (system_supports_poe())
> > +
On Thu, Aug 15, 2024 at 04:46:04PM +0100, Mark Brown wrote:
> On Thu, Aug 15, 2024 at 04:33:25PM +0100, Dave Martin wrote:
> > On Thu, Aug 15, 2024 at 04:05:32PM +0100, Mark Brown wrote:
>
> > > The expectation (at least for arm64) is that the main program will only
> &
On Thu, Aug 15, 2024 at 04:29:54PM +0100, Mark Brown wrote:
> On Thu, Aug 15, 2024 at 04:11:56PM +0100, Dave Martin wrote:
> > On Thu, Aug 15, 2024 at 03:45:45PM +0100, Mark Brown wrote:
> > > On Thu, Aug 15, 2024 at 02:37:22PM +0100, Dave Martin wrote:
>
> > > &g
On Thu, Aug 15, 2024 at 04:05:32PM +0100, Mark Brown wrote:
> On Thu, Aug 15, 2024 at 03:01:21PM +0100, Dave Martin wrote:
>
> > My thought was that if libc knows about shadow stacks, it is probably
> > going to be built to use them too and so would enable shadow stack
>
On Thu, Aug 15, 2024 at 03:45:45PM +0100, Mark Brown wrote:
> On Thu, Aug 15, 2024 at 02:37:22PM +0100, Dave Martin wrote:
>
> > Is there a test for taking and returning from a signal on an alternate
> > (main) stack, when a shadow stack is in use? Sounds like something
> &g
On Wed, Aug 14, 2024 at 05:21:44PM +0100, Mark Brown wrote:
> On Wed, Aug 14, 2024 at 04:09:51PM +0100, Dave Martin wrote:
> > On Thu, Aug 01, 2024 at 01:06:51PM +0100, Mark Brown wrote:
>
> > > + if (add_all || task_gcs_el0_enabled(current)) {
> > > + er
On Wed, Aug 14, 2024 at 05:00:23PM +0100, Mark Brown wrote:
> On Wed, Aug 14, 2024 at 03:51:42PM +0100, Dave Martin wrote:
> > On Thu, Aug 01, 2024 at 01:06:50PM +0100, Mark Brown wrote:
>
> > > + put_user_gcs((unsigned long)sigtramp, gcspr_el0 - 2, &ret);
> >
On Thu, Aug 01, 2024 at 01:06:51PM +0100, Mark Brown wrote:
> Add a context for the GCS state and include it in the signal context when
> running on a system that supports GCS. We reuse the same flags that the
> prctl() uses to specify which GCS features are enabled and also provide the
> current G
On Thu, Aug 01, 2024 at 01:06:50PM +0100, Mark Brown wrote:
> When invoking a signal handler we use the GCS configuration and stack
> for the current thread.
>
> Since we implement signal return by calling the signal handler with a
> return address set up pointing to a trampoline in the vDSO we ne
On Tue, Aug 13, 2024 at 01:55:46PM +0100, Andre Przywara wrote:
> On Tue, 13 Aug 2024 12:00:06 +0100
> Mark Brown wrote:
>
> Hi broonie,
>
> > On Mon, Aug 12, 2024 at 03:09:24PM +0100, Andre Przywara wrote:
> >
> > > + /* Did we find the lowest supported VL? */
> > > + if (use_s
On Mon, Apr 29, 2024 at 04:40:12AM +, Dorine Tipo wrote:
> [PATCH] selftests:arm64: Test PR_SVE_VL_INHERIT after a double fork
Nit: Please follow the same commit message prefix convention as in the
existing code (e.g., try git log tools/testing/selftests/arm64/fp/ ).
[...]
> Add a new test,
25 matches
Mail list logo
