On Mon, Nov 21, 2022 at 7:15 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Mon, 21 Nov 2022 14:47:10 +0100 > KP Singh <kpsingh@xxxxxxxxxx> 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? We absolutely want it enabled in production. > I don't. Speak for yourself, because your employer thinks otherwise.
