BPF for HID drivers

The Human Interface Device (HID) standard dates back to the Windows 95 era. It describes how devices like mice and keyboards present themselves to the host computer, and has created a world where a single driver can handle a wide variety of devices from multiple manufacturers. Or it would have, if there weren't actual device manufacturers involved. In the real world, devices stretch and break the standard, each in its own special way. At the 2022 Linux Plumbers Conference, Benjamin Tissoires described how BPF can be used to simplify the task of supporting HID devices.

人机接口设备（HID）标准可以追溯到 Windows 95 时代。它描述了像鼠标和键盘这样的设备如何向主机计算机呈现自己，并创造了一个理想的世界：单个驱动程序可以支持来自多个厂商的各种设备。但如果没有设备制造商的“创造性”，这或许能成立。现实中，各种设备总是以自己独特的方式拉伸甚至破坏标准。在 2022 年的 Linux Plumbers Conference 上，Benjamin Tissoires 介绍了如何利用 BPF 来简化 HID 设备支持的工作。

Most devices, he began, will work just fine with the kernel's generic HID drivers. That still leaves quite a few that present problems — behavioral quirks that require a special driver to address. Most of the time, that driver need only make a few tweaks to the "report descriptor" provided by the device. This descriptor, the format of which was defined in 2001, describes the exact protocol a device speaks and which capabilities it offers. The kernel contains a long list of tiny drivers that do little beyond tweaking a device's report descriptor to make it adhere to the standard; see drivers/hid/hid-sigmamicro.c for an example. Others, only slightly more complex, will modify input events upon receipt from the device; drivers/hid/hid-ezkey.c shows that type of manipulation.

他首先指出，大多数设备都能很好地与内核的通用 HID 驱动程序配合使用。但仍有不少设备会出现各种问题——行为怪异、需要专用驱动程序来修复。通常，这类驱动程序只需对设备提供的“报告描述符”（report descriptor）做一些小修改即可。报告描述符的格式在 2001 年就已定义，用于描述设备通信协议的细节以及它所具备的功能。内核中包含了许多非常小的驱动程序，它们几乎只负责调整报告描述符以让设备符合标准；例如 drivers/hid/hid-sigmamicro.c。稍微复杂一点的驱动程序会在接收输入事件时修改这些事件；drivers/hid/hid-ezkey.c 就展示了这种操作。

Device manufacturers, of course, show no sign of running out of ideas for new ways to make broken hardware, so the kernel will continue to need to fix things up in new ways. Currently, each quirk fix requires the writing of a new driver, which must then go through the usual kernel review process before getting upstream and, some time later, onto the systems where the offending device is actually used. This is not a great experience for users and creates work for developers; it gets worse if developers lack access to the device in question and must rely on users to build kernels to test proposed fixes. If there were a way to just describe the tweaks needed for a given device, then new devices could be supported quickly on existing kernels, without adding more kernel modules.

当然，设备制造商总是有“新点子”，不断制造出各种“奇葩”的硬件，因此内核也不得不持续以新的方式修复问题。目前，每当出现新的设备怪癖，都需要编写一个新的驱动程序，然后经历完整的内核代码审核流程，才能被合并到上游，再经过一段时间才能出现在实际用户系统上。这种方式对用户而言体验糟糕，对开发者而言工作量也大；更糟的是，当开发者没有设备实物时，只能依赖用户自行构建内核来测试修复方案。如果能有一种机制，仅仅描述针对特定设备的修改，那么就可以在现有内核上快速支持新设备，而无需添加更多内核模块。

That way, of course, is BPF. The idea behind Tissoires's work, which seems likely to be merged for 6.1, is to make it possible to easily create a small program to make a new device work. That program could be dropped into a directory, from which it would be loaded into the kernel. Users will not need to worry about building kernels, and developers can avoid adding more little modules. Instead, the plan is to add these BPF programs to the upstream kernel as needed to support new devices.

而这种机制，正是 BPF。Tissoires 的工作——看起来有望在内核 6.1 中合并——旨在让开发者能够轻松编写一个小型程序，让新设备正常工作。该程序可以放在一个目录中，由内核自动加载。这样，用户无需自己编译内核，开发者也能避免增加更多的小模块。相反，计划是根据需要将这些 BPF 程序添加到上游内核中，用以支持新设备。

But, Tissoires said, once it becomes possible to modify device behavior with BPF, there are other interesting things that can be done. One of those was described as the "HID firewall". Steam, he said, makes game controllers accessible to any process running on the system; a malicious program could rewrite a device's firmware in ways that are unlikely to improve the owner's player ranking. A simple BPF program could block access to the firmware-update endpoint on the device, preventing such attacks.

不过，Tissoires 指出，一旦可以通过 BPF 修改设备行为，就能实现许多有趣的功能。其中一个被称为“HID 防火墙”。他举例说，Steam 让系统上运行的任何进程都能访问游戏控制器；这意味着恶意程序可能会重写设备固件，从而以不利于玩家的方式修改设备。一个简单的 BPF 程序就可以阻止对设备固件更新端点的访问，从而防止这种攻击。

It is also possible to transform devices into something different. The Microsoft Surface Dial, he said, is an interesting input device but, because it is new and different, no software supports it. A BPF program could tweak data coming from the device to make it appear to be a mouse instead, making it usable with existing software.

BPF 还可以用来将设备“变身”为其他类型的设备。他提到，微软的 Surface Dial 是一个很有趣的输入设备，但由于它新颖且独特，尚无软件支持它。通过 BPF 程序，可以调整设备输出的数据，使其在系统看来像是一个鼠标，从而让现有软件能够识别和使用它。

BPF can also be helpful in debugging problems with HID devices. The hidraw device provides useful data now, he said, but it only shows data from a device; there is no way to see the accesses to that device. BPF would make it easy to trace the full interaction with a HID device.

BPF 还可以帮助调试 HID 设备问题。他提到，目前 hidraw 设备可以提供一些有用的数据，但它只能显示来自设备的数据，无法观察到对设备的访问。借助 BPF，就能轻松追踪与 HID 设备的完整交互过程。

BPF programs are executed on data from the device before it is processed by the HID core, he said; that makes it possible for them to modify that data. Multiple programs can be attached to a single device, but the order in which they will be executed is "undefined". Beyond tweaking data, BPF programs can do things like filtering out spurious button clicks. It will also be possible for BPF programs to communicate directly with devices.

他说，BPF 程序在 HID 核心处理设备数据之前执行，因此可以修改这些数据。多个程序可以附加到同一个设备上，但它们的执行顺序是“未定义”的。除了修改数据外，BPF 程序还可以过滤掉误触发的按键事件。未来，还可以让 BPF 程序直接与设备通信。

The implementation relies on tracepoints and, specifically, the error-injection capability. Tracepoints are added at places where changes can usefully be made: reading the report descriptor, receipt of input events, and on a user system call. A set of kfuncs has been provided to facilitate communication with the device; this documentation patch describes the BPF interface in detail.

该实现依赖于 tracepoint，特别是其错误注入（error-injection）功能。tracepoint 被添加在可以进行有用修改的位置，例如读取报告描述符、接收输入事件以及用户系统调用等。内核还提供了一组 kfunc，用于简化与设备的通信；相关文档补丁中详细描述了这一 BPF 接口。

An important limitation, Tissoires said, is that BPF cannot be used to fix devices that are broken (and needed) at boot time. Specifically, that rules out using BPF for most fixes applying to keyboards.

Tissoires 指出，一个重要的限制是：BPF 无法修复那些在系统启动时就需要使用、但又有问题的设备。具体来说，这意味着大多数键盘相关的问题无法通过 BPF 来修复。

One open question, he said in conclusion, is determining the best method for shipping device fixes with the kernel. One approach would be to create a separate module for each BPF source file, but that, once again, leads to the creation of a lot of modules. ("Module" was his word; he may have been speaking about loader programs that run in user space, though). Alternatives would be to create one big module with a lot of BPF programs, or to just ship the fixup programs from the firmware repository instead.

最后，Tissoires 提到一个悬而未决的问题：如何将这些设备修复方案与内核一同发布。一种方法是为每个 BPF 源文件创建独立模块，但这又会导致模块数量爆炸（他使用了“模块”这个词，可能指的是在用户空间运行的加载程序）。替代方案包括：将所有 BPF 程序整合到一个大型模块中，或者干脆从固件仓库中直接发布这些修复程序。