Hacker News Reader

Comment by enasterosophes | Hacker News Reader

It's like a bunch of people correctly predicted a few months ago that maybe this kind of attack surface shouldn't be added into the kernel: https://news.ycombinator.com/item?id=28355754

View on HN

It is almost as if Linux is trying to catch up to Windows in attack surface:

https://arstechnica.com/information-technology/2022/12/criti...

Similar incentives and assumptions lead to similar results.

Maybe if you want to do SMB in kernel-space they should be using the rust bindings

Rust is driver only…for now

Well, one thing written to test-drive Rust for Linux was in-kernel server for 9P, which is probably the closest thing to ksmbd, in-kernel server for SMB, without being identical: https://lwn.net/Articles/907685/

This is hilarious:

> Initially, he had started trying to replace the ksmbd server, but that turned out to not be an ideal project.

if only he perservered...

Quite frankly any new kernel code that interacts with the network, or untrusted data in general, should use Rust to the greatest extent possible.

Why? Is it because you think Rust code in the kernel is memory safe?

It is definitely, undisputably memory safer.

Alternatively using a WASM engine or maybe the kernels built in eBPF.

The overhead would make it not worth it, you'd be better off just running it in userspace.

WASM started to become equivalent of "just rewrite it in Rust" here...

Wait, so I've been lied to? https://www.destroyallsoftware.com/talks/the-birth-and-death...

Language doesn't need to be good to be popular for a long time. PHP was (is) previous "shit but lowest common denominator that everyone uses it" before JS took that mantle.

Also "good" depends on the audience. Ability to cheaply hire a bunch of devs to whip up CRUD app is "good" quality of PHP/JS even if it might not make the language "good" from engineering perspective.

Ignore the JS bashing (it is deserved but irrelevant here).

I was referring to the part explaining the 2028-2040 METAL system where "we" gained 4% execution speed because we stuffed all things into a asm.js VM in kernel that can skip syscall overhead. But it's a joke video anyway.

I’d guess it’d be slightly faster. The WASM or eBPF would add some overhead, however you save on context switching costs from kernel to user land. So for IO heavy stuff like SMB it’d probably perform well.

SMB is a complex network protocol, implementing it without a serious bug somewhere is a serious challenge. Kerberos is another complicated protocol. You have user space FS modules, perhaps it would have been better to make it one? But at the same time you have stuff like TLS ans wireguard in the kernel (SMB is still more complicated imho).

Linux being monolithic and all, I don't think there is a good answer. Hope Microkernels make a comeback.

I am not sure what was so bad about Samba. It was performing better than ksmbd in the sequential access patterns that it typically has:

https://samba.plus/blog/detail/ksmbd-a-new-in-kernel-smb-ser...

Samba also had many severe rce vulns over the years.

So if it weren't in the kernel it would need to run as root, wouldn't it? That gives the attacker nearly the same rights but a much more convenient programming environment.

With CAP_NET_BIND_SERVICE, it doesn't need to be run as root.

And without it can just bind socket then change UID

Binding to a low socket is one thing. But as a file server it needs to access many users' files. That can be done without being root, too. Reducing the attack surface on one end but weakening things a bit on the other. A net gain I might concede, but not completely black and white.

The kernel desperately needs a product manager, who says no.

Reply on news.ycombinator.com