New smb3 kernel server (ksmbd)

http://lkml.iu.edu/hypermail/linux/kernel/2108.3/05470.html

by marcodiego • 5 years ago

97 91 5 years ago

lkml.iu.edu

moonbug• 5 years ago

Can't see why this needs to be in the kernel

oauea• 5 years ago

The target is to provide optimized performance, GPLv2 SMB server

muricula2• 5 years ago

High performance doesn't have to mean being in the kernel.

jasonjayr• 5 years ago

Same reason knfsd is in the kernel: performant file + locking access synchronized with the fs primitives.

The post indicates this is not to replace samba, but to improve the file sharing bits of it.

mkj• 5 years ago

Isn't the main reason for knfsd being in-kernel that it depends on inode number to file lookups? Does samba have the same problem?

The kernel nfs server is IME more robust than userspace options like ganesha, but that seems to mostly be a function of it being widely used - a kernel samba server doesn't have that advantage?

cestith• 5 years ago

It doesn't need to be. Samba works from userspace. This performs better because the fs primitives are in-kernel. It's also reportedly easier to maintain and easier to further optimize as part of the kernel. Everything's a tradeoff.

ape4• 5 years ago

Dumb question: if this (or any other) kernel module crashes does the entire kernel?

muricula2• 5 years ago

Yup! And if an attacker hacks this module they can hijack the kernel. And it can probably be reached by anyone on the same network, or may even be exposed to the internet :|

Aissen2• 5 years ago

Here the official mailing list mirror link:

https://lore.kernel.org/lkml/CAH2r5msoKV7qAgoKipa+QNDJ+xR83Y...

We shipped ksmbd a few months ago to a few million users. We had to iron out a few bugs, but otherwise it works really well (it supports SMBv3.1.1 and is faster than samba).

inshadows• 5 years ago

Who are these millions?

Aissen2• 5 years ago

https://www.nextinpact.com/article/45625/free-integre-suppor...

ammmir• 5 years ago

the wireguardification of the kernel! just kidding, I applaud this welcome performance boost, it's always been tricky to extract the most performance out of Samba, especially over high-latency links, although that's more of an SMB protocol issue than anything else, but hopefully ksmbd helps in that regard.

whoknowswhat112• 5 years ago

WOW! This is fantastic (potentially).

Can this be used as a file server to Windows / Linux / Mac clients? I don't need the AD part, but do need the file serving part that would integrate reasonably with a windows setup.

There was a golden period when Samba shipped on Mac, you could run Samba on linux, and consume it on all platforms (Mac / Windows / Linux) pretty easily.

apetresc• 5 years ago

That’s still the case? I’m on the latest macOS build and I can still mount my Linux boxes’ Samba shares just fine.

dr_hooo• 5 years ago

Apple switched to a proprietary implementation since a couple of versions (due to licensing IIRC), otherwise essentially yes.

rektide2• 5 years ago

there are 7 condescending, mean, negative posts. ~4 neutral posts. this is one of 2 positive, happy posts, and by far the happiest. you deserve a god damned medal.

it's shocking what a bunch of sad sorry sacks there are about. everyone's a critic, conservative & afraid of change, unwilling to see uses. what a terrible crowd here.

yes, this is exactly for setting up a file server for Windows/Linux/Mac, without the AD part, without samba. i wish your positivity had a little stronger basis to it, knew a little better what you were excited about, but hey, given the pick of these negative nancies and you, mercy, i'd take your innocence any day.

brasetvik• 5 years ago

ksmbd is a new kernel module which implements the server side of the SMB3 protocol. […] The bigger goal is to add new features more rapidly […] which are easier to develop on a smaller, more tightly optimized kernel server than for example in Samba.

That seems like a quite significant (external) attack surface to add to the kernel? (With plans on adding more)

slownews4510• 5 years ago

Not directly related but aren't these the folks that are pulling out a lot of the insecure methods from the CIFS client? So that should be a good cleanup on that side. (ie, MD4?)

rektide2• 5 years ago

just don't run/load the module then?

i for one am super excited that i have a much lighter weight option available. for example, on my/my parents openwrt wifi routers to expose files with, in a way that other computers in the house can use.

my fear of security holes is pretty weak. this will be exposed inside the firewall only (at least at first). and i trust that by promoting & moving such a thing into the kernel, we'll have a very involved active community trying to make sure things are safe. we'll notice & catch exploits quickly once they start to be used. the message here of fear & uncertainty does not resound with me. quite the opposite. sunlight is not perfect but it has proven to be a progressive & very adaptive means to disinfect & secure within cybersecurity.

edit: wow, -2, some strong disagreement! not sure what ya'll are so afraid of!! why so conservative? doesn't this seem like progress?

spijdar• 5 years ago

Windows has a long and colorful history full of serious, remotely exploitable vulnerabilities made oh so much worse by the fact they're running inside kernel space. I'm sure there are plenty of people who don't like the idea of bringing this into Linux.

FWIW, these exploits are not all in legacy code. A recent SMB3 vulnerability "SMBGhost" used a lack of bounds checking of compressed data in the new SMB3 compression code, which can be triggered pre-auth.

If that bug is in a user space program, it's a bad bug, but you're at least not (unnecessarily!) opening up your entire kernel to RCE. Even assuming "many eyes find all bugs" some don't want to introduce the risk at all.

iforgotpassword• 5 years ago

Slight tangent, but since the changelog further down mentions both cifsd and ksmbd: For all I know cifs is supposed to be the older name for the same thing (ie an older protocol version). But just like in this case, I still frequently stumble across both terms when reading about/dealing with it. So, is there actually still a difference between those two terms?

accrual• 5 years ago

I thought the same thing when I saw both names mentioned. My understanding is CIFS is an older dialect of SMB that some servers/clients can still fall back on. Here's some key text from an article on the subject [0]:

Most people, when they use either SMB or CIFS, are talking about the same exact thing. The two are interchangeable not only in a discussion but also in application – i.e., a client speaking CIFS can talk to a server speaking SMB and vice versa. Why? Because CIFS is a form of SMB.
1.) The CIFS implementation of SMB is rarely used these days. Under the covers, most modern storage systems no longer use CIFS, they use SMB 2 or SMB 3. In the Windows world, SMB 2 has been the standard as of Windows Vista (2006) and SMB 3 is part of Windows 8 and Windows Server 2012.
2.) CIFS has a negative connotation amongst pedants. SMB 2 and SMB 3 are massive upgrades over the CIFS dialect, and storage architects who are near and dear to file sharing protocols don’t appreciate the misnomer. It’s kind of like calling an executive assistant a secretary.

[0] https://www.varonis.com/blog/cifs-vs-smb/

[1] https://blog.fosketts.net/2012/02/16/cifs-smb/ (related)

chasil2• 5 years ago

Using CIFS (aka SMB1) is "like taking your grandmother to prom: she means well, but she can't really move anymore. Also, it's creepy and gross."

https://techcommunity.microsoft.com/t5/storage-at-microsoft/...

jlokier• 5 years ago

CIFS may be old, slow and insecure.

But as the only SMB version that supports the "Unix Extensions" in practice, it is the only version I found which actually works between a Linux client and Samba serving a unix filesystem that is shared with other things, keeping the basic unix file attributes (symlinks, rwx permissions, etc) intact.

I tried SMB 2 and SMB 3, and many combinations of options on the client side and in Samba. Surely something would yield adequate if not perfect unix file attributes. But no combination worked adequately. Only CIFS.

In theory, SMB 3.1.1 has unix extensions that are supported by the Linux client module. In practice, I found this didn't work. Perhaps it will work one day.

Which is why I have a CIFS mount on my laptop at the moment. It's used every day for work, and I don't know what else I could use to get the same functionality.

You may be thinking, "this is what NFS is for". Alas it's not flexible enough. Samba is being used for its id remapping capabilities (and to a lesser extent to constrain permissions), which are sorely lacking in NFS if you don't have NFSv4, which the file server does not support. (Even if it did it would be difficult to set up adequately.) Ironically, Samba is re-exporting an NFS mount in this case, with Samba configured to provide the id-mapping and permissions-constraining that NFS won't do, and CIFS has to be used to maintain the unix file attributes.

creeble• 5 years ago

In my experience, cifs is the client side, smb[d] is the server side.

On Linux, anyway. cifs has been in the kernel (supporting access to SMB shares, including through SMB 3.1), whereas the user-space samba has always been the only way to get SMB sharing (server-side).

edit: clarification

tw04• 5 years ago

There is absolutely a technical difference, but in 2021 it has become a bit like kleenex. SMB/CIFS are used interchangeably by most folks. CIFS was the specific Microsoft implementation of the original SMB protocol.

https://www.varonis.com/blog/cifs-vs-smb/

mlatu• 5 years ago

Or: problems for a new generation

rfraile• 5 years ago

Hope FreeBSD kernel update their SMB code to a v2, almost.

nrclark• 5 years ago

I hope this doesn't displace Samba.

NFS is a pain to use specifically because it's compiled into the kernel, and reads config files that have to live in /etc. That makes it very hard to run or control as an unprivileged user. It also means that a file in /etc needs to be writeable. That makes NFS servers very hard to start, stop, and configure as part of a test bench.

Kernel NFS also essentially displaced all userspace NFS servers (that I'm aware of anyways). At least, I've never been able to get a userspace one to work.

I like Samba specifically because it's easy to configure, start, and stop from userspace. I don't want to see it get obsoleted.

Spivak• 5 years ago

That makes it very hard to run as an unprivileged user?

Huh? You can't run it as an unprivileged user at all.

You want NFS-Ganesha if you want a userspace NFS server. Development it active and it's the only OSS NFS implementation I've seen that can handle an Active-Active HA configuration with Kerberos.

prpl• 5 years ago

In theory you need CAP_SETUID and maybe a few other to run it with less privileges. That can also be done theoretically with another user than root if you can hack things appropriately. In practice the hacking part is hard.

KitDuncan2• 5 years ago

what about ganesha?

slownews4510• 5 years ago

Samba is GPLv3, this is GPLv2 so they may be serving different communities ultimately. At least where I am GPLv2 - folks are MUCH more comfortable with that.

Not sure but one area would be embedded devices (think security camera with a SD card in it). This would really let them serve a file share for video browsing, without having to give out their keys to the devices themselves (GPLv3 is both viral and has all sorts of what are called anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use).

yjftsjthsd-h5• 5 years ago

anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use

Developers are only "limited" from locking users out of their own device

bombcar2• 5 years ago

Too bad it isn’t gpl2 compatible BSD so Apple could replace their shit version.

m45t3r• 5 years ago

I hope this doesn't displace Samba.

It doesn't seem to be the objective. For one, this is a very old version of SMB protocol (v3, while SMB doesn't have big releases anymore the current one is v4). Also, Samba have the user space tooling that this project explicitly doesn't want to reimplement. And it seems that both implementations are compatible with each other.

It does seem to me that the main objective here is to have a very efficient implementation of SMB for embedded devices.

ArchOversight• 5 years ago

Samba versions don't correlate with the protocol versions.

The latest SMB protocol versions is 3.1.1.

the_angry_angel• 5 years ago

If it helps, as far as I'm aware Ganesha [1] is still widely used, supported, in some cases faster than the kernel implementation, and can be pointed at an arbitrary config file.

[1] https://github.com/nfs-ganesha/nfs-ganesha

dheera• 5 years ago

Isn't NFS also dead? It basically believes you are root if you say you are.

And NFSv4 apparently requires Kerberos? WTF? Was it designed only for MIT use? Why can't they support simple things like SSH keys?

selfhoster112• 5 years ago

NFS is what you use if you want seamless file shares on Linux. Pretty much every other option has been junky or lost me data.

krylon• 5 years ago

The default for NFSv3 is to map client-side root to server-side nobody, unless you explicitly tell it not to. (Which I had to do once to run a diskless workstation with an NFS root filesystem.)

chasil2• 5 years ago

NFSv4 uses idmapd with a defined "domain," unlike direct uid/gid mapping of earlier versions.

When the idmapd daemons on either side cannot agree on the domain, all users will be "squashed" to the default NFS user.

Root is always squashed, unless nosquash is specified in /etc/exports (which goes for earlier protocol versions as well).

NFSv4 [cleartext] does not require kerberos. Kerberos can be used to encrypt the data stream between client and server, but this can also be accomplished with stunnel over TLS (google "nfs encryption" for details).

normaler• 5 years ago

A very clean approach to NFS authentication is using it in combination with wireguard. With NFS you can limit access to certain IPs or IP ranges. With wireguard you add authentication that these IPs are really the users/group of users. Also it adds encryption to the actual file transfer.

pantalaimon2• 5 years ago

gatling has basic Samba support and is really minimal.

If you start it without arguments it will just serve the current directory

tinco4• 5 years ago

I'm getting terrible performance exposing CephFS over samba, I wonder if this might solve those issues as well.

KitDuncan2• 5 years ago

Try MoSMB. It's proprietary, but we have had good results with it on CephFS.

tinco4• 5 years ago

Thanks! I've had this recommended to me before, I'll have to check it out sometime.

jra_samba7• 5 years ago

How are you using Samba -> ceph ? Are you re-exporting a fuse mount or are you using Sambas built-in vfs_ceph module ? The vfs_ceph module should be faster as it's essentially a protocol translator from SMB1/2/3 -> ceph.

tinco4• 5 years ago

The former, thanks! I didn't know about vfs_ceph, I'll check it out!

And thanks for your work on samba, it really is great and it's really enabling our way of working.

rbanffy3• 5 years ago

I’d be more inclined to have syscalls that male Samba’s life easier (and Samba faster) but I’m not sure I want a full SMB server running in kernel space. Didn’t we all agree that servers running as root are a bad idea in general?

mjw1007• 5 years ago

Right.

There was a time quite a while ago when people were writing in-kernel web servers, and they were performing better than userspace ones.

Then of course the response was to work out where the performance drop was coming from and add just enough flexibility to tweak the network behaviour from userspace to fix it.

simcop2387• 5 years ago

One of the goals i believe is to also allow some things like RDMA and other pcie to pcie comms for handling 100Gb+ speeds from direct nvme or similar storage. That's also really hard to do from userspace because it's dealing with hardware and resource controls. Not impossible to do, but certainly not easy either.

rbanffy3• 5 years ago

But then make syscalls for those functions and let Samba (or other file server) call them. The kernel should not be concerned with this if avoidable.

I am probably wrong, because the people behind this are much smarter than me, but, still, adding more application features to the kernel is not something I would encourage without some excellent use case and a good reason not to solve a performance problem by adding more hardware.

Given the option, I’d go with more hardware over making the software more complicated (but faster).

phendrenad2• 5 years ago

Feels like an antipattern. If you're doing high-speed stuff where a context switch to kernel mode and back would kill you, then you really want an RTOS with virtually no attack surface, instead of trying to hack it into the Linux kernel. Because with the Linux kernel, you'll be tempted to run less-secure code on there, because you might become overconfident in the kernel's security (which you've just co-opted by adding a custom in-kernel database engine or something).

EvanAnderson• 5 years ago

Isn't there already a kernel-mode CIFS server in Linux via OpenZFS? (I haven't used ZFS on Linux so this might be a silly question. All my ZFS usage has been on BSD and Solaris.)

pantalaimon2• 5 years ago

How is ZFS related to CIFS?

seabrookmx• 5 years ago

ZFS has an implementation of CIFS (SMB to be pedantic) which is included in OpenZFS. From everything I've read, if you're on Linux you're better off not exposing the shares using the ZFS tooling and instead just use Samba (due to it's greater compatibility).

crmd• 5 years ago

The storage industry has spent literally millions of developer hours over the past decade migrating functions from kernel to user space for reliability, performance, and security reasons. An SMB server in the kernel is not a good idea.

New smb3 kernel server (ksmbd)

Related Stories