All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Jason Wessel <jason.wessel@windriver.com>,
	Douglas Anderson <dianders@chromium.org>
Cc: Daniel Thompson <daniel.thompson@linaro.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: [PATCH v3 0/3] kgdb: Honour the kprobe blocklist when setting breakpoints
Date: Sun, 27 Sep 2020 22:15:28 +0100	[thread overview]
Message-ID: <20200927211531.1380577-1-daniel.thompson@linaro.org> (raw)

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().

v4:
* Fixed KConfig dependencies for HONOUR_KPROBE_BLOCKLIST on kernels
  where MODULES=n
* Add additional debug_core.c functions to the blocklist (thanks Doug)
* Collected a few tags

v3:
* Dropped the single step blocklist checks. It is not proven that the
  code was actually reachable without triggering the catastrophic
  failure flag (which inhibits resume already).
* Update patch description for ("kgdb: Add NOKPROBE labels...") and
  added symbols that are called during trap exit
* Added a new patch to push the breakpoint activation later in the
  flow and ensure the I/O functions are not called with breakpoints
  activated.

v2:
* Reworked after initial RFC to make honouring the blocklist require
  CONFIG_KPROBES. It is now optional but the blocklist will be enabled
  by default for architectures that CONFIG_HAVE_KPROBES

Daniel Thompson (3):
  kgdb: Honour the kprobe blocklist when setting breakpoints
  kgdb: Add NOKPROBE labels on the trap handler functions
  kernel: debug: Centralize dbg_[de]activate_sw_breakpoints

 include/linux/kgdb.h            | 18 ++++++++++++++++++
 kernel/debug/debug_core.c       | 22 ++++++++++++++++++++++
 kernel/debug/gdbstub.c          |  1 -
 kernel/debug/kdb/kdb_bp.c       |  9 +++++++++
 kernel/debug/kdb/kdb_debugger.c |  2 --
 lib/Kconfig.kgdb                | 15 +++++++++++++++
 6 files changed, 64 insertions(+), 3 deletions(-)

--
2.25.4


             reply	other threads:[~2020-09-27 21:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-27 21:15 Daniel Thompson [this message]
2020-09-27 21:15 ` [PATCH v3 1/3] kgdb: Honour the kprobe blocklist when setting breakpoints Daniel Thompson
2020-09-27 21:15 ` [PATCH v3 2/3] kgdb: Add NOKPROBE labels on the trap handler functions Daniel Thompson
2020-09-28 22:44   ` Doug Anderson
2020-09-27 21:15 ` [PATCH v3 3/3] kernel: debug: Centralize dbg_[de]activate_sw_breakpoints Daniel Thompson
2020-09-28 11:17 ` [PATCH v3 0/3] kgdb: Honour the kprobe blocklist when setting breakpoints Daniel Thompson
  -- strict thread matches above, loose matches on Subject: below --
2020-09-14 13:01 Daniel Thompson

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=20200927211531.1380577-1-daniel.thompson@linaro.org \
    --to=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=mhiramat@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.