netdev - [RFC] (re)moving drivers/net/appletalk/cops

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <6c62d7d5-5171-98a3-5287-ecb1df20f574@schmorgal.com>
Date:   Mon, 29 Mar 2021 20:17:30 -0700
From:   Doug Brown <doug@...morgal.com>
To:     linux-firmware@...nel.org, netdev@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Subject: [RFC] (re)moving drivers/net/appletalk/cops_*.h firmware blobs

Hi there,

I've been recently looking at the (ancient) AppleTalk/LocalTalk drivers 
because I've been working on a modern LocalTalk network adapter for 
crazy vintage computer enthusiasts like myself. ;-) In the process, I 
discovered the existence of cops_ffdrv.h and cops_ltdrv.h in the kernel 
source tree (drivers/net/appletalk), which contain proprietary binary 
blobs for old COPS LocalTalk ISA cards with pretty vague licensing in 
terms of ability to redistribute:

> This material is licensed to you strictly for use in conjunction with
> the use of COPS LocalTalk adapters.
> There is no charge for this SDK. And no waranty express or implied
> about its fitness for any purpose. However, we will cheerefully
> refund every penny you paid for this SDK...
> Regards,
>
> Thomas F. Divine
> Chief Scientist

I was surprised that these blobs were still in the kernel source. I 
think it would be nice to remove another set of nonfree blobs from the 
kernel source tree. Sadly, Mr. Divine passed away in 2015, so we can't 
get any further input from him. Is this license acceptable enough to 
migrate these two firmware binaries to linux-firmware and change the 
driver to use request_firmware? Following the process in the 
linux-firmware README to a T is likely not 100% possible because there's 
nothing about permission to redistribute, and I won't be able to get a 
Signed-off-by line. I've been experimenting in QEMU to convert the 
driver to use request_firmware and have something working, but I wanted 
to check before submitting a firmware pull request to start going 
forward with this. Alternatively, if that's not acceptable, would it 
make more sense to follow the route of other drivers like the iSight 
camera driver (drivers/usb/misc/isight_firmware.c), and use 
request_firmware, but supply instructions for extracting the firmware 
binaries from the original source instead of including them in 
linux-firmware? They are still available through archive.org's old 
capture of the (now defunct) company's website, so instructions could be 
provided for downloading and extracting it yourself.

To be honest though -- the whole thing is probably a moot point given 
that the driver in question is for an ISA card. Is there really someone 
out there still using this driver? With that in mind, I suppose another 
option would be to remove the driver altogether. I was hoping somebody 
could provide some input on the correct way to handle this situation. I 
would be happy to take care of it, but I'm unsure of the correct 
approach. Any direction would be much appreciated!

Thanks,
Doug