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: <4c300d45b73aaecc1bfd1ab86502d0711238c698.camel@HansenPartnership.com>
Date: Wed, 24 Jul 2024 16:12:48 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jiri Kosina <jikos@...nel.org>
Cc: Dan Williams <dan.j.williams@...el.com>, 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 Wed, 2024-07-24 at 01:22 +0200, Jiri Kosina wrote:
> On Tue, 23 Jul 2024, James Bottomley wrote:
> 
> > 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.  
> 
> Agreed, but that pretty much underlines my point though.
> 
> The ecosystem didn't get shattered as a result of me having created 
> hidraw.

Yes, we're in agreement on this.  I was just extrapolating to not every
bypass is inherently evil.

> libfido2 is on pretty much everyone's machine now (at least for those
> who need it), and people are using that all the time to authenticate
> to kernel.org/Google/Okta/whatnot. No workflow got broken in the
> process.

Well, there is one use case I can think of that would have the kernel
talking to a fido token (i.e. us having a kernel driver): using it as
the root for trusted and encrypted keys.  It might be very useful for
security features like encrypted device tree or kernel command line
files, or even passing in a private X.509 key to add to the kernel
trusted keyrings or for module signing.   The rush to bypass the kernel
deprived us of thinking about this as an application, but, since the
spec is open, if anyone cares enough, I'm sure it will eventually get
written.

James