netdev - Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1e82a5c97e915144e01dd65575929c15bc0db397.camel@HansenPartnership.com>
Date: Tue, 23 Jul 2024 07:36:24 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jiri Kosina <jikos@...nel.org>, Dan Williams <dan.j.williams@...el.com>
Cc: ksummit@...ts.linux.dev, linux-cxl@...r.kernel.org, 
	linux-rdma@...r.kernel.org, netdev@...r.kernel.org, jgg@...dia.com
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

On Tue, 2024-07-23 at 13:20 +0200, Jiri Kosina wrote:
> On Mon, 8 Jul 2024, Dan Williams wrote:
> 
> > 2/ Device passthrough, kernel passing opaque payloads, is already
> > taken for granted in many subsystems. USB and HID have "raw"
> > interfaces
> 
> Just as a completely random datapoint here: after I implemented
> hidraw inteface long time ago, I was a little bit hesitant about
> really merging it, because there was a general fear that this would
> shatter the HID driver ecosystem, making it difficult for people to
> find proper drivers  for their devices, etc.

The problem with hidraw is that userspace has to understand the device
to use it, but a lot of HID devices (keyboards, mice, serial ports,
etc.) want to fit into an existing ecosystem so they have to have a
kernel driver to avoid having to update all the user applications. 
However, entirely new devices don't have the existing ecosystem
problem.

> Turns out that that didn't happen. Drivers for generic devices are
> still implemented properly in the kernel, and hidraw is mostly used
> for rather specific, one-off solutions, where the vendor's business
> plan is "ship this one appliance and forget forever", which doesn't
> really cause any harm to the whole ecosystem.

That's not entirely true.  FIDO tokens (the ones Konstantin is
recommending for kernel.org access) are an entire class of devices that
use hidraw and don't have a kernel driver.  There's an array of
manufacturers producing them, but the CTAP specification and its
conformance is what keeps a single user mode driver (which is now
present as a separate implementation in all web browsers and the
userspace libfido2) for all of them.  Fido is definitely not a one off,
but on the other hand, not having a kernel driver doesn't seem to harm
the ecosystem and they can get away with it because there was no
existing device type for them to fit into (except, as you say, an array
of incompatible and short lived USB key tokens which annoyed everyone
by having usability limits due to the oneoffness).

James