165
submitted 1 year ago* (last edited 1 year ago) by pedroapero@lemmy.ml to c/linux@lemmy.ml

The next release of the Linux kernel, 6.6 [will] include the KSMBD in-kernel server for the SMB networking protocol, developed by Samsung's Namjae Jeon.

it has faced considerable security testing and as a result it is no longer marked as experimental.

It's compatible with existing Samba configuration files.

But why is KSMBD important? First off, it promises considerable performance gains and better support for modern features such as Remote Direct Memory Access (RDMA)... KSMBD also adds enhanced security, considerably better performance for both single and multi-thread read/write, better stability, and higher compatibility. In the end, hopefully, this KSMBD will also mean easier share setups in Linux without having to jump through the same hoops one must with the traditional Samba setup.

all 19 comments
sorted by: hot top controversial new old
[-] bjoern_tantau@swg-empire.de 51 points 1 year ago

Even if it was tested extensively, why would I want to run any server in the kernel?

[-] taaz@biglemmowski.win 17 points 1 year ago

I guess this is to get some kind of parity with nfsd

[-] bjoern_tantau@swg-empire.de 3 points 1 year ago

Yeah, another thing where I never understood why it was in the kernel.

[-] jonne@infosec.pub 14 points 1 year ago* (last edited 1 year ago)

Yeah, not sure about that either. Unless you have some kind of use case where you need every bit of performance out of this, this stuff belongs in user space.

And if performance was an issue, just throw more/better hardware at it.

[-] tal@kbin.social 19 points 1 year ago* (last edited 1 year ago)

The above text says that the aim is to do RDMA, to let the NIC access memory directly, but I'd think that existing Linux zero-copy interfaces would be sufficient for that.

https://en.wikipedia.org/wiki/Zero-copy

The Linux kernel supports zero-copy through various system calls, such as:

  • sendfile, sendfile64;[9]
  • splice;[10]
  • tee;[11]
  • vmsplice;[12]
  • process_vm_readv;[13]
  • process_vm_writev;[14]
  • copy_file_range;[15]
  • raw sockets with packet mmap[16] or AF_XDP.

So I'd think that the target workload has to be one where you can't just fetch a big chunk of pre-existing data, where you have to interject server-generated data in response to small requests, and even the overhead of switching to userspace to generate some kind of server-generated response is too high.

Which seems like a heck of a niche case.

But it obviously got approval from the kernel team.

googles

https://www.kernel.org/doc/html/next/filesystems/smb/ksmbd.html

The subset of performance related operations belong in kernelspace and the other subset which belong to operations which are not really related with performance in userspace. So, DCE/RPC management that has historically resulted into number of buffer overflow issues and dangerous security bugs and user account management are implemented in user space as ksmbd.mountd. File operations that are related with performance (open/read/write/close etc.) in kernel space (ksmbd). This also allows for easier integration with VFS interface for all file operations.

I guess you could accelerate open and close too.

In all seriousness, I feel like if you're in such a niche situation that you can't afford the overhead of going to userspace for that, (a) there's likely room to optimize your application to request different things and (b) CIFS might not be the best option to be sharing data over the network either.

[-] GenderNeutralBro@lemmy.sdf.org 9 points 1 year ago* (last edited 1 year ago)

The above text says that the aim is to do RDMA, to let the NIC access memory directly

Oh, so the attack surface is much bigger than I realized. The NIC is probably the last thing I'd want writing directly to memory and bypassing the kernel.

I guess none of this will be enabled in desktop distros or even the majority of server distros...right?

[-] Laser@feddit.de 2 points 1 year ago

I was under the impression this is already the norm for network equipment because the vast amount of data is no longer processable by the kernel. In fairness though that equipment most likely doesn't really consume the data but rather just forwards.

[-] FooBarrington@lemmy.world 2 points 1 year ago

Shouldn't io_uring solve the issues with speed between usermode and kernelmode?

[-] drspod@lemmy.ml 50 points 1 year ago

KSMBD is also important in that placing such core server functionality right inside the kernel represents a significant potential attack surface for crackers. As one comment on Hacker News said "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."

Words to live by.

[-] tal@kbin.social 25 points 1 year ago* (last edited 1 year ago)

There have been vulnerabilities on the TCP/IP stack on a number of platforms (maybe all?), and that's a rather smaller attack surface.

EDIT: It also looks like ksmbd has already built itself a bit of a security history:

https://access.redhat.com/solutions/6991749

EDIT2: A bad security history:

https://lwn.net/Articles/871866/

The commit history for ksmbd shows a steady stream of fixes, as expected. Worryingly, though, many of the problems being fixed are clearly security issues — not a good thing in a network filesystem implementation. Examples include:

  • The code to change ownership and permissions did not check existing file permissions first.
  • Failure to validate data lengths could lead to access to invalid data.
  • The server would blindly follow symbolic links during pathname lookup.
  • Numerous failures to validate buffer lengths, such as this one or this one.

All of those fixes were applied after ksmbd landed in the mainline; there are others that came before. Currently, twelve fixes to ksmbd credit Coverity scans in their changelogs.

Those would worry me if they showed up in a production userspace network filesystem.

[-] blobjim@hexbear.net 2 points 1 year ago

I guess if you're just running it in a VM with a passthrough storage device with nothing else running in the VM that could be okay.

[-] JWBananas@startrek.website 21 points 1 year ago

Inb4 systemd-smbd

[-] Rustmilian@lemmy.world 10 points 1 year ago

KSMBD is an opensource In-kernel CIFS/SMB3 server created by Namjae Jeon for Linux Kernel. It's an implementation of SMB/CIFS protocol in kernel space for sharing files and IPC services over network. Initially the target is to provide improved file I/O performances, but the bigger goal is to have some new features which are much easier to develop and maintain inside the kernel and expose the layers fully. Directions can be attributed to sections where SAMBA is moving to few modules inside the kernel to have features like RDMA(Remote direct memory access) to work with actual performance gain.

[-] ProgrammingSocks@pawb.social 1 points 1 year ago

I'm moving to BSD!! Seriously though the Linux kernel shouldn't just continually get more and more bloated... Keep this shit in user space!!

this post was submitted on 16 Sep 2023
165 points (100.0% liked)

Linux

48143 readers
709 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS