I don't think this is actually true (eg. DPDK), but even if it is, you can put the driver in userspace (tun/tap + vfio/libusb/ioport/...) and still use TCP/IP in the kernel.
Speed certainly certainly isn't an issue for AX.25. The protocol typically runs at <10 kbps; the overhead of processing packets in userspace is negligible.
It most commonly runs at 1200bps, used for APRS these days.
You can do a neat trick with this if you set up IP over AX.25, particularly with softmodems. Since you've got IP you can do SSH or TLS over it, right? At least, if you set all the timeouts really long, because some of those packets take a while at 120 bytes per second.
So then you can tune the tones to be a little off the normal frequencies of one side, and play them through speakers with two PCs connected together. When you ssh from one to the other, you will hear the establishment packets and the flurry of packets for every keypress pingponging backwards and forwards between the two systems.
Absolutely brilliant for demonstrating how things like TCP works with retries (plug a mike into it too, shout some interference) and how UDP doesn't, and stuff.
And then you'd be able to hear the difference in the chat between the two machines! That's an amazing demo :-)
I used to use mosh and tmux over 9600bps AX.25 before I had 3G data, a very long time ago. Strictly speaking SSH over amateur radio breaks the rule about encryption but 144MHz is a big place with no-one in it, and you can't pay Ofcom to take an interest in what people do on amateur radio.
that's strictly not true. if I move the code that does TCP from the kernel into the application (not some other daemon, which is perhaps what you're suggesting), then the performance is to the first order the same.
ok, what are the niggly details. we don't have interrupts, and we're running under the general scheduler, so there may be some effects from not getting scheduled as aggressively.
we still need to coordinate through the kernel wrt port bindings, since those are global across the machine, but that's just a tiny bit.
clearly we may be re-opening a door to syn-flooding, since the path to rejection is maybe longer. maybe not, but maybe we can leave the 3-way handshake in the kernel and put the datapath in userspace.
we probably lose rtt-estimates hanging off of routes.
Do you realize AX25 it's just something loaded on demand when the user requires it, and not by default? Do you know the basics on how the systems work bellow your shiny UI's and IDE's?
First, AX25 modules would just lie down in the disk harmless, no AX25 stuff it's loaded unless some user modprobe thems in order to setup some hamradio stack with HamNet and the like.
I see far more security issues with blobs loaded in a so-called GPLv2 kernel everywhere where the tarball almost weights more in blobs than in libre source code. Yet these LLM bootlickers will happily accept whichever non-free firmware on their noses.
Somehow propietary Radeon, Nvidia, some Intel audio drivers for SOCs and the tons of ARM related firmware blobs are not a security issue. At all.
Just kick random bits over the BUS without knowing what really happens with the device. Even if some of them can have full access to the RAM and CPU and the like. That's pretty fine. Ah, yes, IOMMU's and the like. Not enough for some cases. Sorry, but these people can't be serious where the actual multi-CPU based networked computer it's full of opaque bits where you have no control on what they do at all.
For clarity: the example upthread about pwning was TCP/IP, not AX.25.
Also the idea that "there are no local exploits in this kernel code because it's not used by the running system" is like the proximate cause of 80% of local privilege escalation vulnerabilities. Seriously?
... by loading it? There are many ways to get the kernel to suck in a module you can then bang on over sysfs or whatever API it presents. You can have a local exploit in a binary with CAP_SYS_MODULE, subsystems can be fooled into passing uncooked strings to modprobe, users can be fooled into dropping junk into /etc/modprobe.d (instructions for doing so are pervasive in the embedded world and most users think this stuff is safe), etc...
This kind of chicanery is the vanilla pudding of the hacker world. It's everywhere. Suffice it to say that you're simply wrong: NO, it's never OK to argue a subsystem is safe because you personally think it can't be loaded. It 100% can be, that's the easy part.
>users can be fooled into dropping junk into /etc/modprobe.d (instructions for doing so are pervasive in the embedded world and most users think this stuff is safe), etc...
Not an issue for AX25 per se.
If you can fool an user to run root instructions, it's game over, period.
Also releasing the so-called GPLv2 kernel full of propietary blobs where GPU's and even SOC's can take over the whole initialization process (and some devices talk to the CPU directly since DMA times, and I don't think IOMMU's will be 100% safe for this) it's perfecly fine for security.