Received: by 2002:a19:771d:0:0:0:0:0 with SMTP id s29csp1268116lfc; Wed, 1 Jun 2022 13:38:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPIGWvpHr0oc3benZIlhjdvbHukdc/2uKTrAZ7xkardP2H8C9JOGSSeDUqqSreX+WvozHI X-Received: by 2002:a17:902:d504:b0:163:f8e0:94bb with SMTP id b4-20020a170902d50400b00163f8e094bbmr1281266plg.159.1654115929722; Wed, 01 Jun 2022 13:38:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654115929; cv=none; d=google.com; s=arc-20160816; b=PZZOtnGZXYfylaKCD94LTuFlHIRtU6f3SYk6R6j7E8/qSQUdIz/deNEOLIC7zVqZl0 0ZGoGEa0bq9+FJDcIn8wuge1LTYmM1g4rIme0c7H2QJrbzgvxdDKB/kgpyQfijHiuHY6 Oc6nhyEoGh+VHiXVvBOx2v0wqXrZwD2LwIYhdCQdM5pxLLvwQiOjw+8a5wlaGAsMAYqo AX/BEvuwDbQ45O3QPKMkIAA+ZXoH+uNA8gUbGcmkF2MiVfqFiUmll1qS7FI/hYb74F38 2DPGIKzvyFxphnmHS+dPq9oZ0o9gfl646UCMYX7X/SB7xggcuLGevyxnrQ5CkydF41gs /qHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=LHfTPjbR/ocaEKI2euekEd9CUNVAA+DZiRkvQmDrTN0=; b=rdqhBXYVxsf810ri5rK4MoUKi3t+W4GEtl2HgtesvJx94t0nhTQ7AOuMbdAQRuK1HZ rYaajgsRICJtuqJ0oh/uygGlPN+Qzy9/I2f6mYX4WykyIuyrkTyoxxbfwGXdt6Wb8TNB y0ovFf8giBxmToL4z77dP92sdDaZsVT53yl0LQBoxMq+igymclv+qwTumYSnhhEJRDj5 5+7iZRQkqhSSt2KMxN4urS0qgVgZ1+Q0V++OPYB8gj4n+1Vbzjdt+/OgdktqyP2qM7dv 5OqG5fdnu9SsHmdPhnFL58Olo7BRGmhZCjUBAeYHIQGE5NsI08qUxQ3+KwyVHTXAYn3o sdUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cWj2qW6e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id j3-20020a170903028300b001619aaf38b2si4390866plr.65.2022.06.01.13.38.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 13:38:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cWj2qW6e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 37FC2286483; Wed, 1 Jun 2022 12:50:36 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241976AbiE3P6z (ORCPT + 99 others); Mon, 30 May 2022 11:58:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242133AbiE3P6k (ORCPT ); Mon, 30 May 2022 11:58:40 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0CC7DB85C for ; Mon, 30 May 2022 08:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653925812; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LHfTPjbR/ocaEKI2euekEd9CUNVAA+DZiRkvQmDrTN0=; b=cWj2qW6em3UkLnL8lLF3h+s109+cTNhCSf29FcUozL2YwjAgEnMugiBl9yCd+MBLKBOFJv hkdUqdhFFDmTzdek+9+P9VKllpYNLiE++BGH/XKbQIuSVZZUdWaCLsssGqIWxE3+lpodsz lLvDDirTVxvPR5oqnuxjiBcv8r36ChU= Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-568-9_vtsOcnMhqPFkET_wzSnA-1; Mon, 30 May 2022 11:50:10 -0400 X-MC-Unique: 9_vtsOcnMhqPFkET_wzSnA-1 Received: by mail-pg1-f198.google.com with SMTP id 1-20020a630d41000000b003fbeb988042so1205801pgn.1 for ; Mon, 30 May 2022 08:50:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LHfTPjbR/ocaEKI2euekEd9CUNVAA+DZiRkvQmDrTN0=; b=0sS9kstRB9SIkM8VkqEuhL1d+LPzsj/DdNBJbKiOTdoQLIge2xn4Ve0sVe8a1y9/A1 XuRcS/v2qIT2FDFqjuFvGufarqLEL7Yz82YYSPKkuq/iubA1Vh4BtzzLOoaQBY/yLifr kMkmRI+Pw9qf/zf1H3ZECCXM3zDpiBIRLRN2M0F9RnjF/AcyAzRFcIodbs3E86NbSxlh 7z/k93PyRBs/C8ycnP3sUfYNKMc8GNYSmX9SyBAjgVlkpV6kYDphqkFqdi20/zntYE6O DDODn7APTXL7uK4oBBkwvXPZe5poQxd5ut3qRBRO+kniWQ9+dlBmr+qsrKvnJcmsjSAL Hnwg== X-Gm-Message-State: AOAM530Ek/098Qj4ZuDzDSr/NHfXiml6eekvnMu47i9bOFaXvUai/BzT H3Kej95/Q3D/yUN6l4U1H5/LIr2RE5NoZVDpAYYqVonNb1jhCxSjf7K+nGl2nZVMopbMWeqo2Vu DRwT6wi7UsXhsZdlt7qC4U5oJz/ksKfnD8ak/93u8 X-Received: by 2002:a17:902:c412:b0:161:af8b:f478 with SMTP id k18-20020a170902c41200b00161af8bf478mr57106608plk.67.1653925809329; Mon, 30 May 2022 08:50:09 -0700 (PDT) X-Received: by 2002:a17:902:c412:b0:161:af8b:f478 with SMTP id k18-20020a170902c41200b00161af8bf478mr57106583plk.67.1653925809012; Mon, 30 May 2022 08:50:09 -0700 (PDT) MIME-Version: 1.0 References: <20220518205924.399291-1-benjamin.tissoires@redhat.com> <799ae406-ce12-f0d4-d213-4dd455236e49@linux.intel.com> In-Reply-To: <799ae406-ce12-f0d4-d213-4dd455236e49@linux.intel.com> From: Benjamin Tissoires Date: Mon, 30 May 2022 17:49:57 +0200 Message-ID: Subject: Re: [PATCH bpf-next v5 00/17] Introduce eBPF support for HID devices To: Tero Kristo Cc: Greg KH , Jiri Kosina , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Shuah Khan , Dave Marchevsky , Joe Stringer , Jonathan Corbet , lkml , "open list:HID CORE LAYER" , Networking , bpf , "open list:KERNEL SELFTEST FRAMEWORK" , Linux Doc Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tero, On Fri, May 27, 2022 at 9:26 AM Tero Kristo wrote: > > Hi Benjamin, > > I noticed a couple of issues with this series, but was able to > fix/workaround them locally and got my USI program working with it. > > 1) You seem to be missing tools/include/uapi/linux/hid_bpf.h from index, > I wasn't able to compile the selftests (or my own program) without > adding this. It is included from > tools/testing/selftests/bpf/prog_tests/hid.c: #include Hmm... I initially thought that this would be "fixed" when the kernel headers are properly installed, so I don't need to manually keep a duplicate in the tools tree. But now that you mention it, I probably need to do it the way you mention it. > > 2) The limitation of needing to hardcode the size for hid_bpf_get_data() > seems somewhat worrying, especially as the kernel side limits this to > the ctx->allocated_size. I used a sufficiently large number for my > purposes for now (256) which seems to work, but how should I handle my > case where I basically need to read the whole input report and parse > certain portions of it? How does the HID subsystem select the size of > the ctx->allocated_size? The allocated size is based on the maximum size of the reports allowed in the device. It is dynamically computed based on the report descriptor. I also had the exact same issue you mentioned (dynamically retrieve the whole report), and that's why I added a couple of things: - struct hid_bpf_ctx->allocated_size which gives the allocated size, so you can use this as an upper bound in a for loop - the allocated size is guaranteed to be a multiple of 64 bytes. Which means you can have the following for loop: for (i = 0; i * 64 < hid_ctx->allocated_size && i < 64; i++) { data = hid_bpf_get_data(hid_ctx, i * 64, 64); /* some more processing */ } ("i < 64" makes an upper bound of 4KB of data, which should be enough in most cases). Cheers, Benjamin > > -Tero > > On 18/05/2022 23:59, Benjamin Tissoires wrote: > > Hi, > > > > And here comes the v5 of the HID-BPF series. > > > > I managed to achive the same functionalities than v3 this time. > > Handling per-device BPF program was "interesting" to say the least, > > but I don't know if we can have a generic BPF way of handling such > > situation. > > > > The interesting bits is that now the BPF core changes are rather small, > > and I am mostly using existing facilities. > > I didn't managed to write selftests for the RET_PTR_TO_MEM kfunc, > > because I can not call kmalloc while in a SEC("tc") program to match > > what the other kfunc tests are doing. > > And AFAICT, the most interesting bits would be to implement verifier > > selftests, which are way out of my league, given that they are > > implemented as plain bytecode. > > > > The logic is the following (see also the last patch for some more > > documentation): > > - hid-bpf first preloads a BPF program in the kernel that does a few > > things: > > * find out which attach_btf_id are associated with our trace points > > * adds a bpf_tail_call() BPF program that I can use to "call" any > > other BPF program stored into a jump table > > * monitors the releases of struct bpf_prog, and when there are no > > other users than us, detach the bpf progs from the HID devices > > - users then declare their tracepoints and then call > > hid_bpf_attach_prog() in a SEC("syscall") program > > - hid-bpf then calls multiple time the bpf_tail_call() program with a > > different index in the jump table whenever there is an event coming > > from a matching HID device > > > > Note that I am tempted to pin an "attach_hid_program" in the bpffs so > > that users don't need to declare one, but I am afraid this will be one > > more API to handle, so maybe not. > > > > I am also wondering if I should not strip out hid_bpf_jmp_table of most > > of its features and implement everything as a BPF program. This might > > remove the need to add the kernel light skeleton implementations of map > > modifications, and might also possibly be more re-usable for other > > subsystems. But every plan I do in my head involves a lot of back and > > forth between the kernel and BPF to achieve the same, which doesn't feel > > right. The tricky part is the RCU list of programs that is stored in each > > device and also the global state of the jump table. > > Anyway, something to look for in a next version if there is a push for it. > > > > FWIW, patch 1 is something I'd like to get merged sooner. With 2 > > colleagues, we are also working on supporting the "revoke" functionality > > of a fd for USB and for hidraw. While hidraw can be emulated with the > > current features, we need the syscall kfuncs for USB, because when we > > revoke a USB access, we also need to kick out the user, and for that, we > > need to actually execute code in the kernel from a userspace event. > > > > Anyway, happy reviewing. > > > > Cheers, > > Benjamin > > > > [Patch series based on commit 68084a136420 ("selftests/bpf: Fix building bpf selftests statically") > > in the bpf-next tree] > > > > Benjamin Tissoires (17): > > bpf/btf: also allow kfunc in tracing and syscall programs > > bpf/verifier: allow kfunc to return an allocated mem > > bpf: prepare for more bpf syscall to be used from kernel and user > > space. > > libbpf: add map_get_fd_by_id and map_delete_elem in light skeleton > > HID: core: store the unique system identifier in hid_device > > HID: export hid_report_type to uapi > > HID: initial BPF implementation > > selftests/bpf: add tests for the HID-bpf initial implementation > > HID: bpf: allocate data memory for device_event BPF programs > > selftests/bpf/hid: add test to change the report size > > HID: bpf: introduce hid_hw_request() > > selftests/bpf: add tests for bpf_hid_hw_request > > HID: bpf: allow to change the report descriptor > > selftests/bpf: add report descriptor fixup tests > > samples/bpf: add new hid_mouse example > > selftests/bpf: Add a test for BPF_F_INSERT_HEAD > > Documentation: add HID-BPF docs > > > > Documentation/hid/hid-bpf.rst | 528 ++++++++++ > > Documentation/hid/index.rst | 1 + > > drivers/hid/Kconfig | 2 + > > drivers/hid/Makefile | 2 + > > drivers/hid/bpf/Kconfig | 19 + > > drivers/hid/bpf/Makefile | 11 + > > drivers/hid/bpf/entrypoints/Makefile | 88 ++ > > drivers/hid/bpf/entrypoints/README | 4 + > > drivers/hid/bpf/entrypoints/entrypoints.bpf.c | 78 ++ > > .../hid/bpf/entrypoints/entrypoints.lskel.h | 782 ++++++++++++++ > > drivers/hid/bpf/hid_bpf_dispatch.c | 565 ++++++++++ > > drivers/hid/bpf/hid_bpf_dispatch.h | 28 + > > drivers/hid/bpf/hid_bpf_jmp_table.c | 587 +++++++++++ > > drivers/hid/hid-core.c | 43 +- > > include/linux/btf.h | 7 + > > include/linux/hid.h | 29 +- > > include/linux/hid_bpf.h | 144 +++ > > include/uapi/linux/hid.h | 12 + > > include/uapi/linux/hid_bpf.h | 25 + > > kernel/bpf/btf.c | 47 +- > > kernel/bpf/syscall.c | 10 +- > > kernel/bpf/verifier.c | 72 +- > > samples/bpf/.gitignore | 1 + > > samples/bpf/Makefile | 23 + > > samples/bpf/hid_mouse.bpf.c | 134 +++ > > samples/bpf/hid_mouse.c | 157 +++ > > tools/lib/bpf/skel_internal.h | 23 + > > tools/testing/selftests/bpf/config | 3 + > > tools/testing/selftests/bpf/prog_tests/hid.c | 990 ++++++++++++++++++ > > tools/testing/selftests/bpf/progs/hid.c | 222 ++++ > > 30 files changed, 4593 insertions(+), 44 deletions(-) > > create mode 100644 Documentation/hid/hid-bpf.rst > > create mode 100644 drivers/hid/bpf/Kconfig > > create mode 100644 drivers/hid/bpf/Makefile > > create mode 100644 drivers/hid/bpf/entrypoints/Makefile > > create mode 100644 drivers/hid/bpf/entrypoints/README > > create mode 100644 drivers/hid/bpf/entrypoints/entrypoints.bpf.c > > create mode 100644 drivers/hid/bpf/entrypoints/entrypoints.lskel.h > > create mode 100644 drivers/hid/bpf/hid_bpf_dispatch.c > > create mode 100644 drivers/hid/bpf/hid_bpf_dispatch.h > > create mode 100644 drivers/hid/bpf/hid_bpf_jmp_table.c > > create mode 100644 include/linux/hid_bpf.h > > create mode 100644 include/uapi/linux/hid_bpf.h > > create mode 100644 samples/bpf/hid_mouse.bpf.c > > create mode 100644 samples/bpf/hid_mouse.c > > create mode 100644 tools/testing/selftests/bpf/prog_tests/hid.c > > create mode 100644 tools/testing/selftests/bpf/progs/hid.c > > >