From: Masami Hiramatsu <mhiramat@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: will@kernel.org, catalin.marinas@arm.com, mhiramat@kernel.org,
james.morse@arm.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: kprobes: Drop open-coded exception fixup
Date: Mon, 21 Oct 2019 17:49:26 +0900 [thread overview]
Message-ID: <20191021174926.10992282af1c36d721a6747d@kernel.org> (raw)
In-Reply-To: <e70f7b9de7e601b9e4a6fedad8eaf64d304b1637.1571326276.git.robin.murphy@arm.com>
Hi Robin,
On Thu, 17 Oct 2019 16:31:42 +0100
Robin Murphy <robin.murphy@arm.com> wrote:
> The short-circuit call to fixup_exception() from kprobe_fault_handler()
> poses a problem now that the former wants to consume the fault address
> too, since the common kprobes API offers us no way to pass it through.
> Fortunately, however, it works out to be unnecessary:
Thank you for pointing it out!
>
> - uaccess instructions themselves are not probeable, so at most we
> should only ever expect to take a fixable fault from the pre or post
> handlers.
Right. If it is not fixable, we should handle it as a kernel bug.
(to avoid it we can use probe_kernel_read() in kprobe handler)
> - the pre and post handler run with preemption disabled, thus for any
> fault they may cause, an unhandled return from kprobe_page_fault()
> will proceed directly to __do_kernel_fault() thanks to the
> faulthandler_disabled() check.
OK, this is reasonable.
> - __do_kernel_fault() will immediately call fixup_exception() unless
> we're in an EL1 instruction abort, and if we've somehow taken one of
> those on what we think is the middle of a uaccess routine, then the
> world is already very on fire.
OK, this looks good to me.
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Thank you!
>
> Thus we can reasonably drop the call from kprobe_fault_handler() and
> leave uaccess fixups to the regular flow.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> arch/arm64/kernel/probes/kprobes.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index c4452827419b..422fbd5c6c55 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -334,13 +334,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
> */
> if (cur->fault_handler && cur->fault_handler(cur, regs, fsr))
> return 1;
> -
> - /*
> - * In case the user-specified fault handler returned
> - * zero, try to fix up.
> - */
> - if (fixup_exception(regs))
> - return 1;
> }
> return 0;
> }
> --
> 2.21.0.dirty
>
--
Masami Hiramatsu <mhiramat@kernel.org>
prev parent reply other threads:[~2019-10-21 8:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 15:31 Robin Murphy
2019-10-21 8:49 ` Masami Hiramatsu [this message]
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=20191021174926.10992282af1c36d721a6747d@kernel.org \
--to=mhiramat@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@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
all inboxes | Powered by JetHome®