All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Pratyush Anand <panand@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"David A . Long" <dave.long@linaro.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/4] arm64: kprobes: Use arch_populate_kprobe_blacklist()
Date: Mon, 21 Jan 2019 12:20:07 +0000	[thread overview]
Message-ID: <7f840cc8-4e62-e1d7-9035-4361204fc134@arm.com> (raw)
In-Reply-To: <154753353370.31541.14485875717131836689.stgit@devbox>

Hello,

On 15/01/2019 06:25, Masami Hiramatsu wrote:
> Use arch_populate_kprobe_blacklist() instead of
> arch_within_kprobe_blacklist() so that we can see the full
> blacklisted symbols under the debugfs.
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index b9e9758b6534..6c066c34c8a4 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -465,26 +465,30 @@ kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr)
>  	return DBG_HOOK_HANDLED;
>  }
>  
> -bool arch_within_kprobe_blacklist(unsigned long addr)
> +int __init arch_populate_kprobe_blacklist(void)
>  {
> -	if ((addr >= (unsigned long)__kprobes_text_start &&
> -	    addr < (unsigned long)__kprobes_text_end) ||
> -	    (addr >= (unsigned long)__entry_text_start &&
> -	    addr < (unsigned long)__entry_text_end) ||
> -	    (addr >= (unsigned long)__idmap_text_start &&
> -	    addr < (unsigned long)__idmap_text_end) ||

> -	    in_exception_text(addr))

You added this one in the previous patch, but it disappears here.


> -		return true;
> -
> -	if (!is_kernel_in_hyp_mode()) {
> -		if ((addr >= (unsigned long)__hyp_text_start &&
> -		    addr < (unsigned long)__hyp_text_end) ||
> -		    (addr >= (unsigned long)__hyp_idmap_text_start &&
> -		    addr < (unsigned long)__hyp_idmap_text_end))
> -			return true;
> -	}
> -
> -	return false;
> +	int ret;


> +	ret = kprobe_add_area_blacklist((unsigned long)__kprobes_text_start,
> +					(unsigned long)__kprobes_text_end);
> +	if (ret)
> +		return ret;

Now that we have arch_populate_kprobe_blacklist(), does the arch-code need to
blacklist the kprobes section itself?

The weak arch_within_kprobe_blacklist() will test it at kprobe-load time, and
populate_kprobe_blacklist() adds it to the list before it calls
arch_populate_kprobe_blacklist().

Won't this result in duplicate entries?


> +	ret = kprobe_add_area_blacklist((unsigned long)__entry_text_start,
> +					(unsigned long)__entry_text_end);
> +	if (ret)
> +		return ret;

> +	ret = kprobe_add_area_blacklist((unsigned long)__idmap_text_start,
> +					(unsigned long)__idmap_text_end);

> +	if (ret || is_kernel_in_hyp_mode())
> +		return ret;


Hmmm, I think we have a bug here today.

This is saying we can kprobe KVM when we have VHE, because all of KVMs code runs
at the same exception-level as the kernel. Which is true...
But KVM switches VBAR_EL1, so if we run over one of kprobes BRK instructions,
we're going to hyp-panic, because KVM doesn't handle synchronous exceptions from
EL2.

The __hyp_text also contains the guest entry/exit code, which we mustn't probe,
even on VHE.

I think we should always blacklist the __hyp_text, and KVM should mark its
vhe-only functions with __kprobes. I'll post patches for this.


Thanks,

James


> +	ret = kprobe_add_area_blacklist((unsigned long)__hyp_text_start,
> +					(unsigned long)__hyp_text_end);
> +	if (ret)
> +		return ret;
> +	ret = kprobe_add_area_blacklist((unsigned long)__hyp_idmap_text_start,
> +					(unsigned long)__hyp_idmap_text_end);
> +	return ret;
>  }
>  
>  void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-01-21 12:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15  6:23 [PATCH v2 0/4] arm64: kprobes: Update blacklist checking on arm64 Masami Hiramatsu
2019-01-15  6:24 ` [PATCH v2 1/4] arm64: kprobes: Move extable address check into arch_prepare_kprobe() Masami Hiramatsu
2019-01-15  6:24 ` [PATCH v2 2/4] arm64: kprobes: Remove unneeded RODATA check Masami Hiramatsu
2019-01-15 11:20   ` Mark Rutland
2019-01-15  6:25 ` [PATCH v2 3/4] arm64: kprobes: Move exception_text check in blacklist Masami Hiramatsu
2019-01-21 12:08   ` James Morse
2019-01-15  6:25 ` [PATCH v2 4/4] arm64: kprobes: Use arch_populate_kprobe_blacklist() Masami Hiramatsu
2019-01-21 12:20   ` James Morse [this message]
2019-01-21 13:25     ` Masami Hiramatsu
2019-02-08  9:15       ` Will Deacon
2019-02-11 13:10         ` Masami Hiramatsu
2019-02-11 15:58           ` Will Deacon
2019-02-11 16:05             ` Marc Zyngier
2019-02-12 15:28               ` Masami Hiramatsu
2019-01-16 13:40 ` [PATCH v2 0/4] arm64: kprobes: Update blacklist checking on arm64 Will Deacon
2019-01-19 13:31   ` Masami Hiramatsu

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=7f840cc8-4e62-e1d7-9035-4361204fc134@arm.com \
    --to=james.morse@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.long@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=panand@redhat.com \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.