From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96318C433EF for ; Thu, 19 May 2022 11:57:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232024AbiESL45 (ORCPT ); Thu, 19 May 2022 07:56:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237552AbiESL4q (ORCPT ); Thu, 19 May 2022 07:56:46 -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 B759162102 for ; Thu, 19 May 2022 04:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652961403; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vUzlKZtKtiKnTkl0c+yvVz6DAi0GpJ/ajyiMuXYkKV0=; b=IS24Wpo2LIoBzJbMU9ExPpVT++yOueSUkxkF1cySk838mntHKGwnsV0oVYJQ3rv3f3yqwb deziW2nyodUuz/4eAOCcf9swowTfUNfRQDLP8oTzM1W9rhN8XiNaBtkKAvRcA+7cUiP83f hWen40n8aRy3R3henjuPKY18jm8JTZo= Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-632-9wAA94kPPGecafpiWMy8NQ-1; Thu, 19 May 2022 07:56:42 -0400 X-MC-Unique: 9wAA94kPPGecafpiWMy8NQ-1 Received: by mail-pl1-f199.google.com with SMTP id o10-20020a170902d4ca00b00161d8033431so1275233plg.20 for ; Thu, 19 May 2022 04:56:42 -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:content-transfer-encoding; bh=vUzlKZtKtiKnTkl0c+yvVz6DAi0GpJ/ajyiMuXYkKV0=; b=Om9wEZBuGoeNGaTjT9IBjbQ+i5G2JqS7NcMB0ITS14DTuHuevFeOlfSzMowKQf2gsj vLic9RlvwaWevJLf8O7GHTVZOWxtqW6hTZdiXz5DCHdpE37rBveXPAYzd8SR7Ym8hF4g eF9ysz97oyuuG4XXthTHGWD7aAWYrQrwQ29wZ++QDdv0ufrNrY9SzZdb6mW9Cpmqkx/S 2p2pDhODWwaiHr7HkBIg4rJvbgcVi49HjjLZ7Kx+uFBLZUK0UpB5XANem0F+xkazNQcm 087Luj4UX8N1g5Pwv4s+GwxThtf8o8uAFBdg/BBH+INddrVz5JFfTH/4dMJvc1wGrcGx T2Ag== X-Gm-Message-State: AOAM532CL4iW1zKiENWz3lBynk+pLdg0nrBJibq4WBToLN/YicxOmyiA pQDEohHSlO3SyBddLK4CJgLUCrTBW5kh3BiVpASgun3fLgZnugY9Xfi4KQjHQeyi9Tk+FYArQuS P8G17aDlVPxZV60y9rTgG86izy6342uu+z52LdBXZ X-Received: by 2002:a17:902:c412:b0:161:af8b:f478 with SMTP id k18-20020a170902c41200b00161af8bf478mr4521227plk.67.1652961401566; Thu, 19 May 2022 04:56:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwaJcMg0BaVxCTdCDQ3mQxkDhNi5bxy54g0yctOXIo/JTNwcXdo8zjGgzXssPr6OROkM+zoGvNENhA/pSXCpxY= X-Received: by 2002:a17:902:c412:b0:161:af8b:f478 with SMTP id k18-20020a170902c41200b00161af8bf478mr4521208plk.67.1652961401301; Thu, 19 May 2022 04:56:41 -0700 (PDT) MIME-Version: 1.0 References: <20220518205924.399291-1-benjamin.tissoires@redhat.com> <87ee0p951b.fsf@toke.dk> In-Reply-To: <87ee0p951b.fsf@toke.dk> From: Benjamin Tissoires Date: Thu, 19 May 2022 13:56:30 +0200 Message-ID: Subject: Re: [PATCH bpf-next v5 00/17] Introduce eBPF support for HID devices To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Christoph Hellwig , 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 , Tero Kristo , lkml , "open list:HID CORE LAYER" , Networking , bpf , "open list:KERNEL SELFTEST FRAMEWORK" , Linux Doc Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 19, 2022 at 12:43 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Benjamin Tissoires writes: > > > On Thu, May 19, 2022 at 10:39 AM Christoph Hellwig = wrote: > >> > >> On Thu, May 19, 2022 at 10:20:35AM +0200, Greg KH wrote: > >> > > are written using a hip new VM? > >> > > >> > Ugh, don't mention UDI, that's a bad flashback... > >> > >> But that is very much what we are doing here. > >> > >> > I thought the goal here was to move a lot of the quirk handling and > >> > "fixup the broken HID decriptors in this device" out of kernel .c co= de > >> > and into BPF code instead, which this patchset would allow. > > > > Yes, quirks are a big motivation for this work. Right now half of the > > HID drivers are less than 100 lines of code, and are just trivial > > fixes (one byte in the report descriptor, one key mapping, etc...). > > Using eBPF for those would simplify the process from the user point of > > view: you drop a "firmware fix" as an eBPF program in your system and > > you can continue working on your existing kernel. > > How do you envision those BPF programs living, and how would they be > distributed? (In-tree / out of tree?) > As Greg mentioned in his reply, report descriptors fixups don't do much besides changing a memory buffer at probe time. So we can either have udev load the program, pin it and forget about it, or we can also have the kernel do that for us. So I envision the distribution to be hybrid: - for plain fixups where no userspace is required, we should distribute those programs in the kernel itself, in-tree. This series already implements pre-loading of BPF programs for the core part of HID-BPF, but I plan on working on some automation of pre-loading of these programs from the kernel itself when we need to do so. Ideally, the process would be: * user reports a bug * developer produces an eBPF program (and maybe compile it if the user doesn't have LLVM) * user tests/validates the fix without having to recompile anything * developer drops the program in-tree * some automated magic happens (still unclear exactly how to define which HID device needs which eBPF program ATM) * when the kernel sees this exact same device (BUS/VID/PID/INTERFACE) it loads the fixup - the other part of the hybrid solution is for when userspace is heavily involved (because it exports a new dbus interface for that particular feature on this device). We can not really automatically preload the BPF program because we might not have the user in front of it. So in that case, the program would be hosted alongside the application, out-of-the-tree, but given that to be able to call kernel functions you need to be GPL, some public distribution of the sources is required. Cheers, Benjamin