[PATCH v4 15/29] arm64: handle PKEY/POE faults
Joey Gouly
joey.gouly at arm.com
Thu Aug 1 09:01:10 PDT 2024
On Thu, Jul 25, 2024 at 04:57:09PM +0100, Dave Martin wrote:
> On Fri, May 03, 2024 at 02:01:33PM +0100, Joey Gouly wrote:
> > If a memory fault occurs that is due to an overlay/pkey fault, report that to
> > userspace with a SEGV_PKUERR.
> >
> > Signed-off-by: Joey Gouly <joey.gouly at arm.com>
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Will Deacon <will at kernel.org>
> > ---
> > arch/arm64/include/asm/traps.h | 1 +
> > arch/arm64/kernel/traps.c | 12 ++++++--
> > arch/arm64/mm/fault.c | 56 ++++++++++++++++++++++++++++++++--
> > 3 files changed, 64 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
> > index eefe766d6161..f6f6f2cb7f10 100644
> > --- a/arch/arm64/include/asm/traps.h
> > +++ b/arch/arm64/include/asm/traps.h
> > @@ -25,6 +25,7 @@ try_emulate_armv8_deprecated(struct pt_regs *regs, u32 insn)
> > void force_signal_inject(int signal, int code, unsigned long address, unsigned long err);
> > void arm64_notify_segfault(unsigned long addr);
> > void arm64_force_sig_fault(int signo, int code, unsigned long far, const char *str);
> > +void arm64_force_sig_fault_pkey(int signo, int code, unsigned long far, const char *str, int pkey);
> > void arm64_force_sig_mceerr(int code, unsigned long far, short lsb, const char *str);
> > void arm64_force_sig_ptrace_errno_trap(int errno, unsigned long far, const char *str);
> >
> > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > index 215e6d7f2df8..1bac6c84d3f5 100644
> > --- a/arch/arm64/kernel/traps.c
> > +++ b/arch/arm64/kernel/traps.c
> > @@ -263,16 +263,24 @@ static void arm64_show_signal(int signo, const char *str)
> > __show_regs(regs);
> > }
> >
> > -void arm64_force_sig_fault(int signo, int code, unsigned long far,
> > - const char *str)
> > +void arm64_force_sig_fault_pkey(int signo, int code, unsigned long far,
> > + const char *str, int pkey)
> > {
> > arm64_show_signal(signo, str);
> > if (signo == SIGKILL)
> > force_sig(SIGKILL);
> > + else if (code == SEGV_PKUERR)
> > + force_sig_pkuerr((void __user *)far, pkey);
>
> Is signo definitely SIGSEGV here? It looks to me like we can get in
> here for SIGBUS, SIGTRAP etc.
>
> si_codes are not unique between different signo here, so I'm wondering
> whether this should this be:
>
> else if (signo == SIGSEGV && code == SEGV_PKUERR)
>
> ...?
>
>
> > else
> > force_sig_fault(signo, code, (void __user *)far);
> > }
> >
> > +void arm64_force_sig_fault(int signo, int code, unsigned long far,
> > + const char *str)
> > +{
> > + arm64_force_sig_fault_pkey(signo, code, far, str, 0);
>
> Is there a reason not to follow the same convention as elsewhere, where
> -1 is passed for "no pkey"?
>
> If we think this should never be called with signo == SIGSEGV &&
> code == SEGV_PKUERR and no valid pkey but if it's messy to prove, then
> maybe a WARN_ON_ONCE() would be worth it here?
>
Anshuman suggested to separate them out, which I did like below, I think that
addresses your comments too?
diff --git arch/arm64/kernel/traps.c arch/arm64/kernel/traps.c
index 215e6d7f2df8..49bac9ae04c0 100644
--- arch/arm64/kernel/traps.c
+++ arch/arm64/kernel/traps.c
@@ -273,6 +273,13 @@ void arm64_force_sig_fault(int signo, int code, unsigned long far,
force_sig_fault(signo, code, (void __user *)far);
}
+void arm64_force_sig_fault_pkey(int signo, int code, unsigned long far,
+ const char *str, int pkey)
+{
+ arm64_show_signal(signo, str);
+ force_sig_pkuerr((void __user *)far, pkey);
+}
+
void arm64_force_sig_mceerr(int code, unsigned long far, short lsb,
const char *str)
{
diff --git arch/arm64/mm/fault.c arch/arm64/mm/fault.c
index 451ba7cbd5ad..1ddd46b97f88 100644
--- arch/arm64/mm/fault.c
+++ arch/arm64/mm/fault.c
- arm64_force_sig_fault(SIGSEGV, si_code, far, inf->name);
+ if (si_code == SEGV_PKUERR)
+ arm64_force_sig_fault_pkey(SIGSEGV, si_code, far, inf->name, pkey);
+ else
+ arm64_force_sig_fault(SIGSEGV, si_code, far, inf->name);
Thanks,
Joey
More information about the linux-arm-kernel
mailing list