BPF List
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: KP Singh <kpsingh@kernel.org>
Cc: Chris Mason <clm@meta.com>, Mark Rutland <mark.rutland@arm.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Florent Revest <revest@chromium.org>, bpf <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Brendan Jackman <jackmanb@google.com>,
	markowsky@google.com, Masami Hiramatsu <mhiramat@kernel.org>,
	Xu Kuohai <xukuohai@huawei.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC 0/1] BPF tracing for arm64 using fprobe
Date: Mon, 21 Nov 2022 10:15:37 -0500	[thread overview]
Message-ID: <20221121101537.674f5aca@gandalf.local.home> (raw)
In-Reply-To: <CACYkzJ613nhXViBpDuGWeEWzjfSJjbB1=KNpYtNDC6Xn7yizbw@mail.gmail.com>

On Mon, 21 Nov 2022 14:47:10 +0100
KP Singh <kpsingh@kernel.org> wrote:

> This annotation already exists, i.e. ALLOW_ERROR_INJECTION
> 
> Users, with CONFIG_FUNCTION_ERROR_INJECTION, can already modify return
> values of kernel functions using kprobes and the failure injection
> framework [1] for functions annotated with ALLOW_ERROR_INJECTION.
> 
> BPF just provides another way to do the same thing with "modify
> return" programs and this also respects the error injection list [2]
> and users can *only* attach these programs to the functions annotated
> with ALLOW_ERROR_INJECTION.

WAIT!

Looking at the Kconfigs, I see

CONFIG_FUNCTION_ERROR_INJECTION is set when
CONFIG_HAVE_FUNCTION_ERROR_INJECTION is set, and when CONFIG_KPROBES is set.

And ALLOW_ERROR_INJECTION() is set when CONFIG_FUNCTION_ERROR_INJECTION is.

There's no way to turn it off on x86 except by disabling kprobes!

WTF!

I don't want a kernel that can add error injection just because kprobes is
enabled. There's two kinds of kprobes. One that is for visibility only (for
tracing) and one that can be used for functional changes. I want the
visibility without the ability to change the kernel. The visibility portion
is very useful for security, where as the modifying one can be used to
circumvent security.

As kprobes are set in most production environments, so is error injection.
Do we really want error injection enabled on production environments?
I don't.

I think we need this patch ASAP!

-- Steve

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c3c0b077ade3..9ee72d8860c3 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1874,8 +1874,14 @@ config NETDEV_NOTIFIER_ERROR_INJECT
 	  If unsure, say N.
 
 config FUNCTION_ERROR_INJECTION
-	def_bool y
+	bool "Fault-injections of functions"
 	depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
+	help
+	  Add fault injections into various functions that are annotated with
+	  ALLOW_ERROR_INJECTION() in the kernel. BPF may also modify the return
+	  value of theses functions. This is useful to test error paths of code.
+
+	  If unsure, say N
 
 config FAULT_INJECTION
 	bool "Fault-injection framework"

  parent reply	other threads:[~2022-11-21 15:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-08 22:06 [RFC 0/1] BPF tracing for arm64 using fprobe Florent Revest
2022-11-08 22:06 ` [RFC 1/1] bpf: Invoke tracing progs using fprobe on archs without direct call Florent Revest
2022-11-17  2:41 ` [RFC 0/1] BPF tracing for arm64 using fprobe Alexei Starovoitov
2022-11-17 13:33   ` Masami Hiramatsu
2022-11-17 16:50     ` Alexei Starovoitov
2022-11-18 16:26       ` Mark Rutland
2022-11-17 17:16   ` Steven Rostedt
2022-11-17 21:55     ` Chris Mason
2022-11-17 22:40       ` Steven Rostedt
2022-11-18 16:34         ` Mark Rutland
2022-11-18 16:45           ` Steven Rostedt
2022-11-18 17:44             ` Chris Mason
2022-11-18 18:06               ` Steven Rostedt
2022-11-18 18:52                 ` Chris Mason
2022-11-21 13:47                   ` KP Singh
2022-11-21 14:16                     ` Peter Zijlstra
2022-11-21 14:23                       ` KP Singh
2022-11-21 15:15                     ` Steven Rostedt [this message]
2022-11-21 15:29                       ` KP Singh
2022-11-21 15:39                         ` Steven Rostedt
2022-11-21 16:16                         ` Jiri Kosina
2022-11-21 15:40                       ` Alexei Starovoitov
2022-11-21 15:45                         ` Steven Rostedt
2022-11-21 15:55                           ` Borislav Petkov
2022-11-21 10:09                 ` Peter Zijlstra
2022-11-21 14:40                   ` Masami Hiramatsu
2022-11-18 16:18       ` Mark Rutland
2022-11-17 13:16 ` 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=20221121101537.674f5aca@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=clm@meta.com \
    --cc=daniel@iogearbox.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jackmanb@google.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=markowsky@google.com \
    --cc=mhiramat@kernel.org \
    --cc=peterz@infradead.org \
    --cc=revest@chromium.org \
    --cc=torvalds@linux-foundation.org \
    --cc=xukuohai@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox