Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 2 Dec 2022 11:30:39 -0800
From:   Alexei Starovoitov <alexei.starovoitov@gmail.com>
To:     Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Chris Mason <clm@meta.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Borislav Petkov <bp@alien8.de>,
        LKML <linux-kernel@vger.kernel.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Kees Cook <keescook@chromium.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        KP Singh <kpsingh@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Florent Revest <revest@chromium.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] error-injection: Add prompt for function error injection
Message-ID: <20221202193039.jle5fek5t5tff2lp@macbook-pro-6.dhcp.thefacebook.com>
References: <Y3vSQo85ofkfD/L8@zn.tnic>
 <CAADnVQLJFnu6gARdZ7ckgxeGaSv70jHBiQo+W=zDKO0-ELFGcQ@mail.gmail.com>
 <Y3ymzAYRyH5IWEe/@zn.tnic>
 <3fa8ec60-dd96-c41f-ea46-8856bf855949@meta.com>
 <20221122132905.12a8d5ad@gandalf.local.home>
 <a53e8c6d-b0e5-72bf-1aba-07609c9cf1bf@meta.com>
 <20221130143719.07e36277d1471b83e9a1b627@linux-foundation.org>
 <CAADnVQ+KLXPhowdBZq0PvGOq5tv4ovNtNCvGBXHQBkVbz4UVkg@mail.gmail.com>
 <CAHk-=wjeq1m=9mU17WzfRQ1W6N0SgKHY-e2J35SpppWwUUBFbQ@mail.gmail.com>
 <c9912b24-f611-29b8-28e1-5e8be0d5ad41@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c9912b24-f611-29b8-28e1-5e8be0d5ad41@redhat.com>
Precedence: bulk

On Fri, Dec 02, 2022 at 03:55:38PM +0100, Benjamin Tissoires wrote:
> 
> 
> On 12/1/22 22:13, Linus Torvalds wrote:
> > On Thu, Dec 1, 2022 at 8:59 AM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > > 
> > > The hid-bpf framework depends on it.
> > 
> > Ok, this is completely unacceptably disgusting hack.
> 
> [foreword: I have read the other replies, just replying to this one
> because it is the explicit ask for a fix]
> 
> > 
> > That needs fixing.
> > 
> > > Either hid-bpf or bpf core can add
> > > "depends on FUNCTION_ERROR_INJECTION"
> > 
> > No, it needs to be narrowed down a lot. Nobody sane wants error
> > injection just because they want some random HID thing.
> > 
> > And no, BPF shouldn't need it either.
> > 
> > This needs to be narrowed down to the point where HID can say "I want
> > *this* particular call to be able to be a bpf call.
> 
> So, would the following be OK? I still have a few concerns I'll explain
> after the patch.
> 
> ---
> From 1290561304eb3e48e1e6d727def13c16698a26f1 Mon Sep 17 00:00:00 2001
> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Date: Fri, 2 Dec 2022 12:40:29 +0100
> Subject: [PATCH] bpf: do not rely on ALLOW_ERROR_INJECTION for fmod_ret
> 
> The current way of expressing that a non-bpf kernel component is willing
> to accept that bpf programs can be attached to it and that they can change
> the return value is to abuse ALLOW_ERROR_INJECTION.
> This is debated in the link below, and the result is that it is not a
> reasonable thing to do.
> 
> An easy fix is to keep the list of valid functions in the BPF verifier
> in the same way we keep the non-sleepable ALLOW_ERROR_INJECTION ones.
> However, this kind of defeat the point of being able to add bpf APIs in
> non-BPF subsystems, so we probably need to rethink that part.
> 
> 
> Link: https://lore.kernel.org/all/20221121104403.1545f9b5@gandalf.local.home/
> Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>  drivers/hid/bpf/hid_bpf_dispatch.c  |  2 --
>  drivers/hid/bpf/hid_bpf_jmp_table.c |  1 -
>  kernel/bpf/verifier.c               | 20 +++++++++++++++++++-
>  3 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
> index 3c989e74d249..d1f6a1d4ae60 100644
> --- a/drivers/hid/bpf/hid_bpf_dispatch.c
> +++ b/drivers/hid/bpf/hid_bpf_dispatch.c
> @@ -44,7 +44,6 @@ __weak noinline int hid_bpf_device_event(struct hid_bpf_ctx *ctx)
>  {
>  	return 0;
>  }
> -ALLOW_ERROR_INJECTION(hid_bpf_device_event, ERRNO);
>  u8 *
>  dispatch_hid_bpf_device_event(struct hid_device *hdev, enum hid_report_type type, u8 *data,
> @@ -105,7 +104,6 @@ __weak noinline int hid_bpf_rdesc_fixup(struct hid_bpf_ctx *ctx)
>  {
>  	return 0;
>  }
> -ALLOW_ERROR_INJECTION(hid_bpf_rdesc_fixup, ERRNO);
>  u8 *call_hid_bpf_rdesc_fixup(struct hid_device *hdev, u8 *rdesc, unsigned int *size)
>  {
> diff --git a/drivers/hid/bpf/hid_bpf_jmp_table.c b/drivers/hid/bpf/hid_bpf_jmp_table.c
> index 579a6c06906e..207972b028d9 100644
> --- a/drivers/hid/bpf/hid_bpf_jmp_table.c
> +++ b/drivers/hid/bpf/hid_bpf_jmp_table.c
> @@ -103,7 +103,6 @@ __weak noinline int __hid_bpf_tail_call(struct hid_bpf_ctx *ctx)
>  {
>  	return 0;
>  }
> -ALLOW_ERROR_INJECTION(__hid_bpf_tail_call, ERRNO);
>  int hid_bpf_prog_run(struct hid_device *hdev, enum hid_bpf_prog_type type,
>  		     struct hid_bpf_ctx_kern *ctx_kern)
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 225666307bba..4eac440d659f 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -24,6 +24,7 @@
>  #include <linux/bpf_lsm.h>
>  #include <linux/btf_ids.h>
>  #include <linux/poison.h>
> +#include <linux/hid_bpf.h>
>  #include "disasm.h"
> @@ -14827,6 +14828,20 @@ static int check_non_sleepable_error_inject(u32 btf_id)
>  	return btf_id_set_contains(&btf_non_sleepable_error_inject, btf_id);
>  }
> +/* Manually tag fmod_ret functions to not misuse ALLOW_ERROR_INJECTION */
> +BTF_SET_START(btf_modify_return)
> +#if CONFIG_HID_BPF
> +BTF_ID(func, hid_bpf_device_event)
> +BTF_ID(func, hid_bpf_rdesc_fixup)
> +BTF_ID(func, __hid_bpf_tail_call)
> +#endif /* CONFIG_HID_BPF */
> +BTF_SET_END(btf_modify_return)
> +
> +static int check_function_modify_return(u32 btf_id)
> +{
> +	return btf_id_set_contains(&btf_modify_return, btf_id);
> +}
> +
>  int bpf_check_attach_target(struct bpf_verifier_log *log,
>  			    const struct bpf_prog *prog,
>  			    const struct bpf_prog *tgt_prog,
> @@ -15047,7 +15062,10 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
>  				bpf_log(log, "can't modify return codes of BPF programs\n");
>  				return -EINVAL;
>  			}
> -			ret = check_attach_modify_return(addr, tname);
> +			ret = -EINVAL;
> +			if (!check_function_modify_return(btf_id) ||
> +			    check_attach_modify_return(addr, tname))
> +				ret = 0;
>  			if (ret) {
>  				bpf_log(log, "%s() is not modifiable\n", tname);
>  				return ret;
> -- 
> 2.38.1
> ---
> 
> While this patch removes the need for ALLOW_ERROR_INJECTION it has a
> couple of drawbacks:
> - suddenly we lose the nice separation of concerns between bpf core and
> its users (HID in my case)
> - it would need to be changed in 6.3 simply because of the previous
> point, so it is just a temporary fix.

Agree, but it works short term.
A silver lining is BTF_SET approach consumes 4 bytes per mark
while ALLOW_ERROR_INJECTION consumes 16 bytes for struct error_injection_entry
and then another 48 bytes per mark for struct ei_entry.

An alternative would be to define a known prefix like "bpf_modret_"
or "bpf_hook_" and rename these three functions.

Then there will be no need for #include <linux/hid_bpf.h> in bpf core.

> So I am not sure if this would qualify HID-BPF for 6.2. Please speak up.

Since that was the only thing I think it's fine to stay in the queue.