All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jason Wessel <jason.wessel@windriver.com>,
	Douglas Anderson <dianders@chromium.org>,
	Peter Zijlstra <peterz@infradead.org>,
	sumit.garg@linaro.org, pmladek@suse.com,
	sergey.senozhatsky@gmail.com, will@kernel.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	kgdb-bugreport@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, patches@linaro.org
Subject: Re: [PATCH v2 0/3] kgdb: Honour the kprobe blacklist when setting breakpoints
Date: Fri, 17 Jul 2020 22:48:26 +0900	[thread overview]
Message-ID: <20200717224826.80f8353e5dfdfaab22421385@kernel.org> (raw)
In-Reply-To: <20200716151943.2167652-1-daniel.thompson@linaro.org>

Hi Daniel,

On Thu, 16 Jul 2020 16:19:40 +0100
Daniel Thompson <daniel.thompson@linaro.org> wrote:

> kgdb has traditionally adopted a no safety rails approach to breakpoint
> placement. If the debugger is commanded to place a breakpoint at an
> address then it will do so even if that breakpoint results in kgdb
> becoming inoperable.
> 
> A stop-the-world debugger with memory peek/poke intrinsically provides
> its operator with the means to hose their system in all manner of
> exciting ways (not least because stopping-the-world is already a DoS
> attack ;-) ). Nevertheless the current no safety rail approach is
> difficult to defend, especially given kprobes can provide us with plenty
> of machinery to mark the parts of the kernel where breakpointing is
> discouraged.
> 
> This patchset introduces some safety rails by using the existing kprobes
> infrastructure and ensures this will be enabled by default on
> architectures that implement kprobes. At present it does not cover
> absolutely all locations where breakpoints can cause trouble but it will
> block off several avenues, including the architecture specific parts
> that are handled by arch_within_kprobe_blacklist().

This series looks good to me.

Acked-by: Masami Hiramatsu <mhiramat@kernel.org>

To fix the build error with ipw2x00 driver, please feel free to
include my fix patch.

Thank you,

> 
> 
> Daniel Thompson (3):
>   kgdb: Honour the kprobe blocklist when setting breakpoints
>   kgdb: Use the kprobe blocklist to limit single stepping
>   kgdb: Add NOKPROBE labels on the trap handler functions
> 
>  include/linux/kgdb.h        | 19 +++++++++++++++++++
>  kernel/debug/debug_core.c   | 25 +++++++++++++++++++++++++
>  kernel/debug/gdbstub.c      | 10 +++++++++-
>  kernel/debug/kdb/kdb_bp.c   | 17 +++++++++++------
>  kernel/debug/kdb/kdb_main.c | 10 ++++++++--
>  lib/Kconfig.kgdb            | 14 ++++++++++++++
>  6 files changed, 86 insertions(+), 9 deletions(-)
> 
> --
> 2.25.4
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

      parent reply	other threads:[~2020-07-17 13:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16 15:19 [PATCH v2 0/3] kgdb: Honour the kprobe blacklist when setting breakpoints Daniel Thompson
2020-07-16 15:19 ` [PATCH v2 1/3] kgdb: Honour the kprobe blocklist " Daniel Thompson
2020-07-16 20:48   ` kernel test robot
2020-07-17  8:13     ` Masami Hiramatsu
2020-07-17  8:42       ` [PATCH] kprobes: Remove show_registers() function prototype Masami Hiramatsu
2020-07-17 22:39   ` [PATCH v2 1/3] kgdb: Honour the kprobe blocklist when setting breakpoints Doug Anderson
2020-07-16 15:19 ` [PATCH v2 2/3] kgdb: Use the kprobe blocklist to limit single stepping Daniel Thompson
2020-07-17 22:39   ` Doug Anderson
2020-07-20  8:07     ` Daniel Thompson
2020-07-21 21:04       ` Doug Anderson
2020-09-04 15:22         ` Daniel Thompson
2020-07-16 15:19 ` [PATCH v2 3/3] kgdb: Add NOKPROBE labels on the trap handler functions Daniel Thompson
2020-07-17 22:39   ` Doug Anderson
2020-07-20  8:13     ` Daniel Thompson
2020-07-21 21:22       ` Doug Anderson
2020-09-04 15:40         ` Daniel Thompson
2020-07-17 13:48 ` 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=20200717224826.80f8353e5dfdfaab22421385@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=daniel.thompson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=jason.wessel@windriver.com \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=sumit.garg@linaro.org \
    --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 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.