[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y4ogRH7zWLpmVXzJ@mit.edu>
Date: Fri, 2 Dec 2022 10:56:52 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Chris Mason <clm@...a.com>,
Steven Rostedt <rostedt@...dmis.org>,
Borislav Petkov <bp@...en8.de>,
LKML <linux-kernel@...r.kernel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Kees Cook <keescook@...omium.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
KP Singh <kpsingh@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Florent Revest <revest@...omium.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Christoph Hellwig <hch@...radead.org>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>
Subject: Re: [PATCH] error-injection: Add prompt for function error injection
On Thu, Dec 01, 2022 at 05:41:29PM -0800, Alexei Starovoitov wrote:
>
> The fault injection framework disables individual syscall with zero performance
> overhead comparing to LSM and seccomp mechanisms.
> BPF is not involved here. It's a kprobe in one spot.
> All other syscalls don't notice it.
> It's an attractive way to improve security.
>
> A BPF prog over syscall can filter by user, cgroup, task and give fine grain
> control over security surface.
> tbh I'm not aware of folks doing "syscall disabling" through command line like
> above (I've only seen it through bpf), but it doesn't mean that somebody will
> not start complaining that their script broke, because distro disabled fault
> injection.
>
> So should we split FUNCTION_ERROR_INJECTION kconfig into two ?
> And do default N for things like should_failslab() and
> default Y for syscalls?
How about calling the latter something like bpf syscall hooks, and not
using the terminology "error injection" in relation to system calls?
I think that might be less confusing.
- Ted
Powered by blists - more mailing lists