KSMBD Declared Stable – No Longer “Experimental” – In Linux 6.6 | Hacker News Reader

KSMBD Declared Stable – No Longer “Experimental” – In Linux 6.6

phoronix.com

51 pointsLinuxBender19 comments

I'm kinda of the opinion that things listening on the network shouldn't be in-kernel.

Instead, the kernel interfaces should be improved to allow userspace applications to get the same performance benefits. For example, RDMA could be arranged from userspace by having a sendfile() like syscall suitable for telling the kernel that RDMA requests should be satisfied from a certain file handle. Perhaps even seccomp bpf could be used for constructing more complex response packets without needing a context switch to the userspace application.

io_uring already supports zero-copy networking (it's basically an RDMA API after all), and I believe the latest versions of Samba use it to great effect. I'm pretty confident this server could be ported entirely to userspace and maybe even get better performance by avoiding the userspace listener for DCE/RPC.

You know the real reason behind this was to get a GPL2'd Samba that (other) people would be forced to support, right?

Plenty hw manufacturers still won't touch the GPLv3 Samba with a ten-foot pole but do not want to commit to support a fork themselves with all the CVEs it would entail over the years. By putting it in the kernel where it'll have high visibility and with some excuse about performance requirements, at least someone may take the bait later on and maintain this one for free. May even become more popular than Samba itself. Win win!

> By putting it in the kernel where

... they repeat the same mistakes MS did with Windows. /s

But wouldn't it better to find a way to run it in userland for safety?

I know NFS was already part of the kernel. And I presume that by living inside the kernel there is a tight integration with file buffers/caching, and probably some extra performance too. Is that the main motivation here?

Perhaps it's obvious, but I'll ask anyway: what are the advantages in moving this into kernel space?

Performance? Better integration with filesystems? Ease of use?

Perhaps it's obvious but I'll ask the opposite: how large are the possible negatives security wise for this?

Unless this is formally proven or rewritten in a safer language, you'll have to pay me in solid gold to use such a CVE factory waiting to happen.

Apparently this is a Samsung project. Why does Samsung invest resources in a project like this? They don't sell any storage systems.

They do? Samsung is a major provider of datacenter SSDs. They don't sell any storage appliances, but they still benefit from more applications and increased demand for their products. Being able to fully leverage SSD performance over SMB would probably translate in a lot of sales.

Same reason Western Digital sponsors btrfs development, or at least used to.

That is not something to be part of kernel. I don't know why Linux people allow such large attack surface into a kernel.

Wow this already had a security vulnerability from not handling `..`. Not reassuring.

I am really worried that this experimental thing was included (although not by default) in "stable" OpenWrt version for more than a year. How many routers were pwned?

Remember when we used to make fun of Windows for putting random bullshit in the kernel "for performance reasons"?

And then they stopped doing that. Because it was stupid.

I hope this is mainly for running on your router; the efficency gains still matter there and it is single purpose enough that you would primarally be concerned with whatevere implemented the server.

Having it listening on a workstation containing sensative information I would much prefer an older more isolatable userapace implementation.

Even if this is faster than Samba... the max. transfer speed will be dictated by the client running Windows, surely.

RDMA tends to run at 100 Gbps rates and microseconds of latency. In many cases, a data transfer can occur without the CPU running much OS code at all - it's all done by the network hardware DMA'ing the right memory from one machine, across the network, and into the right place in RAM of another machine. It is often faster than reading from local SSD.

One datacenter use is to find another machine on the network who already has a file you want to load to RAM, and loading that file across the network from them rather than reading the file from your local SSD, simply because it is faster to do so.

RAM is close to Tbps rates and ~100 nanoseconds of latency.

The algorithm for locating the machine that has an in-memory copy is likely more expensive than just loading directly from disk.

Reply on news.ycombinator.com