lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 2 Dec 2022 11:30:39 -0800 From: Alexei Starovoitov <alexei.starovoitov@...il.com> To: Benjamin Tissoires <benjamin.tissoires@...hat.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> Subject: Re: [PATCH] error-injection: Add prompt for function error injection 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@...il.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@...hat.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@...il.com> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@...hat.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.
Powered by blists - more mailing lists