[ajross]

> more modern protocols (in userspace)

That's really it. The list of things that "need" to be in the kernel is shrinking steadily, and the downsides of having C code running in elevated privilege levels are increasing. None of that is about LLMs at all, except to the extent that it's a notable inflection point in a decades-scale curve.

The future, and we basically all agree, puts complexities like protocol handling and state in daemons and leaves only the hardware, process and I/O management in the kernel.

Basically, Tannenbaum was right about the design but wrong about the schedule and path to get there.

[sylware]

kernel/user space context switching, in high performance context has to be seriously evaluated.

And this is very dependent on the hardware programming interface of the devices.

Look at AMD who is investigating hardware user-level queues for their GPUs (dunno if this is possible because of VMID stuff)

[ajross]

> kernel/user space context switching, in high performance context has to be seriously evaluated.

Of course. But that's true for all userspace solutions too, and there are many options for async APIs (io_uring et. al.) which work to address that.

The point is that you want the IP stack (or whatever) to be passing stuff around on unix domain sockets for every packet. It's that you want it running in its own memory domain.

[anthk]

Except it's several times slower doing TCP/IP in userspace with programs than having a proper kernel for it, that's it, Hurd.

[rwmj]

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.

[duskwuff]

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.

[ErroneousBosh]

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.

[anthk]

- Lower the MTU

- Use Mosh instead of SSH

- Spawn TMUX in the remote machine to send less bits per session

I tried Mosh+Tmux with 2.7 KBPS (and less) when I was using a data plan. It worked perfectly fine, no delay or barely noticeable.

[ErroneousBosh]

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.

[convolvatron]

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.

none of that suggests 'several times slower'

[pixl97]

"Get Pwn3d server times faster!"

Seemingly we've been writing kernels for years, and they still are full of security holes.

[anthk]

p0wned from where? Where's the vector attack?

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.

[ajross]

> p0wned from where? Where's the vector attack?

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?

[anthk]

How can I exploit an unloaded module?

[ajross]

... 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.

[varispeed]

But hardware manufacturers love it! Excuse to sell new faster machines.

[anthk]

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.

[subscribed]

With the current lead times and the prices of the fast, complicated silicone? I don't think so :)