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 2A085C433EF for ; Thu, 19 May 2022 11:46:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231764AbiESLqy (ORCPT ); Thu, 19 May 2022 07:46:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229878AbiESLqi (ORCPT ); Thu, 19 May 2022 07:46:38 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DB06D60A95 for ; Thu, 19 May 2022 04:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652960793; 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=GSpkaZjpG+wr9/klHZRZ2SJRW1tcfr1HJfk966Tzpq8=; b=OLe8A5nmF45CHu9F560R5KMoJMuMVa5+SSAJxO94FCsAXAYI6UujmpHw81Jij5WiiU7lHg F5CLeFO2JyoZ1Da/IpLKkBbDGSNuQo23WZLZ0SJO3hAJf/cuyqNKJ2EhVsbi/JbckGDqKH VYPhPM94BvylVR7WdTN3BSqqF83CqAo= Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-655-JS2AgIvqPlyl38ixthzUdA-1; Thu, 19 May 2022 07:46:32 -0400 X-MC-Unique: JS2AgIvqPlyl38ixthzUdA-1 Received: by mail-pl1-f200.google.com with SMTP id x23-20020a170902b41700b0015ea144789fso2486319plr.13 for ; Thu, 19 May 2022 04:46:32 -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=GSpkaZjpG+wr9/klHZRZ2SJRW1tcfr1HJfk966Tzpq8=; b=WfIS/N+GAMv+LoVLPtfH4j1Vzdp4BdenpqXSH6ZAkpLjaGBcdYaeDACMm5eF7UYzo+ p3UwLAJIhTEJdwTuhgdVNBvn50LWq1J8VxfL6PrFueOYf42xr9Rsz2kp3pcOLZD4PqXR V5AAUmq/4qlYgcUezmGrKLI+GlaRSj3Yz/yFplndhC9ZRPv/LEvurTZFjX9QeLGIMybT zdFTPL6bJQJlWtLSZsQ2D4ba5/X5B/M1T+hDebbR7ASHyLizy/y0UMC2Z6zWHxk2gqYH hY1Qru+28QhADeZDdwjoMS0Z59ndVUA2ikmPvA3Ov8qHMSmMOV/6dyaIjCNmS2LQ8pgU w9Tg== X-Gm-Message-State: AOAM532NSt69KBe95ctuKSoawokxrcVIqLlTM0iLhn8CzUIty6gUjq+D /WtS5g969tWOUVu3D7r86j33jx4bQiaRg/Nzb8TlHYdDFQrVa1xziyr8NzzOrbIQqkagxOxA0M4 4FvOCvoZ+dMrwtzU/Xtn3C/UatZiSeDI8qi7YcCJ3 X-Received: by 2002:a17:903:22c6:b0:15f:14e1:1518 with SMTP id y6-20020a17090322c600b0015f14e11518mr4389715plg.116.1652960791499; Thu, 19 May 2022 04:46:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzioMf82ETXq8PfZUw04Ya3sdzxwtRppBH/zQS6f6PkiKtChfcyE8u9CczNO3BytCe9N5VvBeRF1NwdZOPfyio= X-Received: by 2002:a17:903:22c6:b0:15f:14e1:1518 with SMTP id y6-20020a17090322c600b0015f14e11518mr4389693plg.116.1652960791232; Thu, 19 May 2022 04:46:31 -0700 (PDT) MIME-Version: 1.0 References: <20220518205924.399291-1-benjamin.tissoires@redhat.com> In-Reply-To: From: Benjamin Tissoires Date: Thu, 19 May 2022 13:46:19 +0200 Message-ID: Subject: Re: [PATCH bpf-next v5 00/17] Introduce eBPF support for HID devices To: Greg KH Cc: Christoph Hellwig , 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 19, 2022 at 12:32 PM Greg KH wrote: > > On Thu, May 19, 2022 at 01:38:58AM -0700, 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 code > > > and into BPF code instead, which this patchset would allow. > > > > > > So that would just be exception handling. I don't think you can write a > > > real HID driver here at all, but I could be wrong as I have not read the > > > new patchset (older versions of this series could not do that.) > > > > And that "exception handling" is most of the driver. > > For a number of "small" drivers, yes, that's all there is as the > hardware is "broken" and needs to be fixed up in order to work properly > with the hid core code. An example of that would be hid-samsung.c which > rewrites the descriptors to be sane and maps the mouse buttons properly. > > But that's it, after initialization that driver gets out of the way and > doesn't actually control anything. From what I can tell, this patchset > would allow us to write those "fixup the mappings and reports before the > HID driver takes over" into ebpf programs. > > It would not replace "real" HID drivers like hid-rmi.c that has to > handle the events and do other "real" work here. > > Or I could be reading this code all wrong, Benjamin? You get it right. hid-rmi is a good example of something that can not sanely be done with eBPF. We can do some filtering on the events (dropping one event, changing one other), but anything outside that would not be possible. This driver does a lot of scheduling, synchronisation, and various setup that would require a lot of back and forth between userspace and BPF/kernel, which makes it definitively not fit for a BPF implementation. > > But even if it would allow us to write HID drivers as ebpf, what is > wrong with that? It's not a licensing issue (this api is only allowed > for GPL ebpf programs), it should allow us to move a bunch of in-kernel > drivers into smaller ebpf programs instead. The one thing I also like with eBPF is that it is safe. When you declare an array of bytes, the verifier enforces we don't go outside of the boundaries. I know rust is coming, but compared to plain C, that is much better, even if more restrictive. And it will also prevent some potential bugs where we have a report fixup that writes outside of the reserved memory. > > It's not like this ebpf HID driver would actually work on any other > operating system, right? I guess Microsoft could create a gpl-licensed > ebpf HID layer as well? As Windows allows vendors to do all of this > horrible HID fixups in userspace today anyway, I strongly doubt they > would go through the effort to add a new api like this for no valid > reason. OTOH, managing to push Microsoft to implement HID-BPF would be some achievement :) (just kidding). Cheers, Benjamin