linux-kernel - Re: [PATCH 01/10] appletalk: remove localtalk and ppp support

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <3cb4bb96-1651-4179-9c32-507937282d7d@app.fastmail.com>
Date:   Mon, 09 Oct 2023 19:29:11 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Rodolfo Zitellini" <rwz@...ro.org>,
        "Arnd Bergmann" <arnd@...nel.org>
Cc:     "Jakub Kicinski" <kuba@...nel.org>,
        Netdev <netdev@...r.kernel.org>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        linux-wireless@...r.kernel.org,
        "Johannes Berg" <johannes@...solutions.net>,
        linux-wpan@...r.kernel.org,
        "Michael Hennerich" <michael.hennerich@...log.com>,
        "Paolo Abeni" <pabeni@...hat.com>,
        "Eric Dumazet" <edumazet@...gle.com>,
        "David S . Miller" <davem@...emloft.net>,
        linux-kernel@...r.kernel.org, "Doug Brown" <doug@...morgal.com>
Subject: Re: [PATCH 01/10] appletalk: remove localtalk and ppp support

On Mon, Oct 9, 2023, at 18:49, Rodolfo Zitellini wrote:
>> From: Arnd Bergmann <arnd@...db.de>
>> 
>> The last localtalk driver is gone now, and ppp support was never fully
>> merged, so clean up the appletalk code by removing the obvious dead
>> code paths.
>> 
>> Notably, this removes one of the two callers of the old .ndo_do_ioctl()
>> callback that was abused for getting device addresses and is now
>> only used in the ieee802154 subsystem, which still uses the same trick.
>> 
>> The include/uapi/linux/if_ltalk.h header might still be required
>> for building userspace programs, but I made sure that debian code
>> search and the netatalk upstream have no references it it, so it
>> should be fine to remove.
>> 
>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>
> Hi!
> I’ve been working on a new LocalTalk interface driver for the last 
> couple months, do you think it would be possible to at least postpone 
> the removal of LT a bit?
>
> It is a driver for an open source device called TashTalk 
> (https://github.com/lampmerchant/tashtalk), which runs on a PIC micro 
> that does all the LT interfacing, and communicates back via serial to 
> the host system. My driver is relatively simple and works very well 
> with netatalk 2.2 (which is still maintained and still has support for 
> AppleTalk). The driver is basically complete and trsted and I was 
> preparing to submit a patch.
>
> Still having LocalTalk in my view has many advantages for us 
> enthusiasts that still want to bridge old machines to the current world 
> without modifications, for example for printing on modern printers, 
> netbooting, sharing files and even tcp/ip. All this basically works out 
> of the box via the driver, Linux and available userspace tools 
> (netatalk, macipgw).
>
> The old ISA cards supported by COPS were basically unobtanium even 20 
> years ago, but the solution of using a PIC and a serial port is very 
> robust and much more furure-proof. We also already have a device that 
> can interface a modern machine directly via USB to LocalTalk.
>
> The development of the TashTalk has been also extensively discussed on 
> thr 68KMLA forum 
> (https://68kmla.org/bb/index.php?threads/modtashtalk-lt0-driver-for-linux.45031/)
>
> I hope the decision to remove LocalTalk can be reconsidered at least 
> for the time being so there is a chance to submit a new, modern device 
> making use of this stack.

Nothing is decided, I'm just proposing my patch as a cleanup
for now. It would be nice to still drop the ndo_do_ioctl function
though, at least in some form. When your driver actually makes
it into the kernel, you can find a different method of communicating
the address between the socket interface and the device driver.

I can see a few ways this could work out:

- add a custom callback pointer to struct atalk_iface to
  get and set the address for phase1 probing instead of going
  through the ioctl

- rewrite the probing logic in aarp.c more widely, and improve
  the userspace interface in the process by introducing a netlink
  interface

- Move your entire driver into userspace and go to the kernel
  using tun/tap. This has the added benefit of avoiding a lot
  of the complexity of the tty line discipline code you have.

      Arnd