From: Peter Collingbourne <pcc@google.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Kostya Serebryany <kcc@google.com>,
Evgenii Stepanov <eugenis@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Will Deacon <will@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH] arm64: Expose original FAR_EL1 value in sigcontext
Date: Wed, 25 Mar 2020 10:41:34 -0700 [thread overview]
Message-ID: <CAMn1gO6nq1P2Z1byYWdO44WRoxhPX6FxyOS3eYc6G2BZ7yKJ2w@mail.gmail.com> (raw)
In-Reply-To: <20200325131023.GN3901@mbp>
On Wed, Mar 25, 2020 at 6:10 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> Hi Peter,
>
> On Thu, Mar 12, 2020 at 10:17:55AM -0700, Peter Collingbourne wrote:
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index fde59981445ca..290ea59c68b85 100644
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -22,7 +22,6 @@ static void notrace el1_abort(struct pt_regs *regs, unsigned long esr)
> > unsigned long far = read_sysreg(far_el1);
> >
> > local_daif_inherit(regs);
> > - far = untagged_addr(far);
> > do_mem_abort(far, esr, regs);
> > }
> > NOKPROBE_SYMBOL(el1_abort);
>
> Would we get a signal on faults triggered by the kernel? Anyway, I'm
> fine with this change for consistency and may help with the fault
> information printed by the kernel with khwasan or (later) MTE.
It doesn't look like we would. As far as I can tell all of the signal
injection paths are guarded with if (user_mode(regs)) and such. Agreed
with the consistency argument.
> > @@ -104,7 +103,6 @@ static void notrace el0_da(struct pt_regs *regs, unsigned long esr)
> >
> > user_exit_irqoff();
> > local_daif_restore(DAIF_PROCCTX);
> > - far = untagged_addr(far);
> > do_mem_abort(far, esr, regs);
> > }
> > NOKPROBE_SYMBOL(el0_da);
> > diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
> > index 0b727edf41046..985cd44decf62 100644
> > --- a/arch/arm64/kernel/hw_breakpoint.c
> > +++ b/arch/arm64/kernel/hw_breakpoint.c
> > @@ -730,7 +730,7 @@ static u64 get_distance_from_watchpoint(unsigned long addr, u64 val,
> > return 0;
> > }
> >
> > -static int watchpoint_handler(unsigned long addr, unsigned int esr,
> > +static int watchpoint_handler(unsigned long far, unsigned int esr,
> > struct pt_regs *regs)
> > {
> > int i, step = 0, *kernel_step, access, closest_match = 0;
> > @@ -741,6 +741,7 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
> > struct debug_info *debug_info;
> > struct arch_hw_breakpoint *info;
> > struct arch_hw_breakpoint_ctrl ctrl;
> > + unsigned long addr = untagged_addr(far);
> >
> > slots = this_cpu_ptr(wp_on_reg);
> > debug_info = ¤t->thread.debug;
>
> Why do we need to untag this here? Have you hit any bug? This function
> gets the original FAR_EL1 value, untagged (via elX_dbg()), and we clear
> the tag further down in get_distance_from_watchpoint().
You're right, I missed that this was going via elX_dbg() rather than
an abort handler. In fact, this would seem to be a potential userspace
break because the now-untagged address is also stored in
counter_arch_bp(wp)->trigger, which is exposed to userspace via
ptrace_hbptriggered in arch/arm64/kernel/ptrace.c. I've reverted this
part in v2.
> > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> > index 339882db5a915..48e8b6c7b5369 100644
> > --- a/arch/arm64/kernel/signal.c
> > +++ b/arch/arm64/kernel/signal.c
> > @@ -55,6 +55,7 @@ struct rt_sigframe_user_layout {
> >
> > unsigned long fpsimd_offset;
> > unsigned long esr_offset;
> > + unsigned long far_offset;
> > unsigned long sve_offset;
> > unsigned long extra_offset;
> > unsigned long end_offset;
> > @@ -383,6 +384,7 @@ static int parse_user_sigframe(struct user_ctxs *user,
> > break;
> >
> > case ESR_MAGIC:
> > + case FAR_MAGIC:
> > /* ignore */
> > break;
> >
> > @@ -581,6 +583,11 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
> > sizeof(struct esr_context));
> > if (err)
> > return err;
> > +
> > + err = sigframe_alloc(user, &user->far_offset,
> > + sizeof(struct far_context));
> > + if (err)
> > + return err;
>
> It looks fine, I think it makes sense to only expose the raw FAR_EL1
> when we also expose the ESR_EL1 (via set_thread_esr()).
>
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index 85566d32958f5..2ca2de1ff43be 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -41,7 +41,7 @@
> > #include <asm/traps.h>
> >
> > struct fault_info {
> > - int (*fn)(unsigned long addr, unsigned int esr,
> > + int (*fn)(unsigned long far, unsigned int esr,
> > struct pt_regs *regs);
> > int sig;
> > int code;
> > @@ -320,9 +320,11 @@ static void __do_kernel_fault(unsigned long addr, unsigned int esr,
> > die_kernel_fault(msg, addr, esr, regs);
> > }
> >
> > -static void set_thread_esr(unsigned long address, unsigned int esr)
> > +static void set_thread_esr(unsigned long far, unsigned int esr)
>
> We might as well rename this to set_thread_far_esr().
Done in v2.
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-25 17:41 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 17:17 [PATCH] arm64: Expose original FAR_EL1 value in sigcontext Peter Collingbourne
2020-03-25 13:10 ` Catalin Marinas
2020-03-25 17:41 ` Peter Collingbourne [this message]
2020-03-25 17:40 ` [PATCH v2] " Peter Collingbourne
2020-03-26 16:45 ` Catalin Marinas
2020-03-27 7:56 ` Will Deacon
2020-03-27 11:39 ` Catalin Marinas
2020-03-27 19:26 ` Peter Collingbourne
2020-03-27 19:19 ` [PATCH v3] " Peter Collingbourne
2020-04-22 14:25 ` Catalin Marinas
2020-04-29 21:08 ` Will Deacon
2020-04-29 21:42 ` Peter Collingbourne
2020-05-04 17:03 ` Will Deacon
2020-05-07 17:57 ` [PATCH v4] arm64: Expose FAR_EL1 tag bits " Peter Collingbourne
2020-05-08 2:01 ` [PATCH v5] " Peter Collingbourne
2020-05-12 16:25 ` Catalin Marinas
2020-05-13 18:09 ` [PATCH v6] " Peter Collingbourne
2020-05-13 20:28 ` Dave Martin
2020-05-15 0:58 ` Peter Collingbourne
2020-05-18 9:53 ` Dave Martin
2020-05-19 22:00 ` Peter Collingbourne
2020-05-20 8:55 ` Will Deacon
2020-05-20 9:26 ` Dave Martin
2020-05-21 2:28 ` Peter Collingbourne
2020-05-21 2:29 ` [PATCH v6 0/3] " Peter Collingbourne
2020-05-21 2:29 ` [PATCH v6 1/3] signal: Allow architectures to store arch-specific data in kernel_siginfo Peter Collingbourne
2020-05-21 2:29 ` [PATCH v6 2/3] arm64: Move fault address and fault code into kernel_siginfo Peter Collingbourne
2020-05-21 13:34 ` kbuild test robot
2020-05-21 2:29 ` [PATCH v6 3/3] arm64: Expose FAR_EL1 tag bits in sigcontext Peter Collingbourne
2020-05-21 12:35 ` [PATCH v6] " Eric W. Biederman
2020-05-21 18:03 ` Peter Collingbourne
2020-05-21 19:24 ` Eric W. Biederman
2020-05-21 20:48 ` Peter Collingbourne
2020-06-08 18:12 ` Peter Collingbourne
2020-06-08 18:14 ` [PATCH v7] arm64: Expose FAR_EL1 tag bits in siginfo Peter Collingbourne
[not found] ` <20200623020134.16655-1-pcc@google.com>
[not found] ` <87sgemrlgc.fsf@x220.int.ebiederm.org>
2020-06-23 14:38 ` [PATCH v8] " Dave Martin
2020-06-23 17:47 ` Eric W. Biederman
2020-06-24 0:40 ` Peter Collingbourne
2020-06-24 9:28 ` Dave Martin
2020-06-24 16:51 ` Peter Collingbourne
2020-06-24 17:12 ` Dave Martin
2020-06-24 19:51 ` Peter Collingbourne
2020-07-06 16:41 ` Dave Martin
2020-07-06 19:20 ` Peter Collingbourne
2020-07-07 14:19 ` Dave Martin
2020-07-07 19:07 ` Peter Collingbourne
2020-07-08 11:00 ` Dave Martin
2020-07-08 13:58 ` Dave Martin
2020-07-08 22:21 ` Peter Collingbourne
2020-07-13 13:24 ` Dave Martin
2020-07-13 20:50 ` Peter Collingbourne
2020-07-14 17:36 ` Dave Martin
2020-08-18 3:16 ` Peter Collingbourne
2020-08-18 13:50 ` Dave Martin
2020-06-23 14:57 ` Dave Martin
2020-05-26 13:03 ` [PATCH v6] arm64: Expose FAR_EL1 tag bits in sigcontext Dave Martin
2020-04-30 9:50 ` [PATCH v3] arm64: Expose original FAR_EL1 value " Catalin Marinas
2020-04-30 9:59 ` Will Deacon
2020-04-30 13:34 ` Catalin Marinas
2020-05-04 10:19 ` Dave Martin
2020-05-07 17:55 ` Peter Collingbourne
2020-05-13 17:27 ` Dave Martin
2020-05-13 18:00 ` Peter Collingbourne
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=CAMn1gO6nq1P2Z1byYWdO44WRoxhPX6FxyOS3eYc6G2BZ7yKJ2w@mail.gmail.com \
--to=pcc@google.com \
--cc=andreyknvl@google.com \
--cc=catalin.marinas@arm.com \
--cc=eugenis@google.com \
--cc=kcc@google.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=rth@twiddle.net \
--cc=vincenzo.frascino@arm.com \
--cc=will@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).