KSMBD Finally Reaches 'Stable' State in Release Candidate for Linux Kernel 6.6 (theregister.com) 46
When Linus Torvalds announced Linux kernel 6.6's first release candidate, it included a newly-stable version of KSMBD, which is Samsung's in-kernel server for the SMB protocol (for sharing files/folders/printers over a network).
An announcement in 2021 had said that "For many cases the current userspace server choices were suboptimal either due to memory footprint, performance or difficulty integrating well with advanced Linux features."
LWN noted at the time that Linux has been using "the user-space Samba solution since shortly after the beginning." In a sense, ksmbd is not meant to compete with Samba; indeed, it has been developed in cooperation with the Samba project. It is, however, meant to be a more performant and focused solution than Samba is; at this point, Samba includes a great deal of functionality beyond simple file serving. Ksmbd claims significant performance improvements on a wide range of benchmarks...One other reason — which tends to be spoken rather more quietly — is that a new implementation can be licensed under GPLv2, while Samba is GPLv3.
The Register notes that when Samba switched to GPL 3, "one result was that Apple dropped Samba from Mac OS X and replaced it with its own, in-house server called SMBX." And they also remember that a month after its debut in 2021, "Linux sysadmins got to enjoy KSMBD's first security exploit." What's changed now is that it has faced considerable security testing and as a result it is no longer marked as experimental. It's been developed with the assistance of the Samba team, which itself documents how to use it. It's compatible with existing Samba configuration files. As the team says, "It is not meant to replace the existing Samba fileserver 'smbd', but rather be an extension and will integrate with Samba in the future...."
KSMBD is also important in that placing such core server functionality right inside the kernel represents a significant potential attack surface for crackers... The new bcachefs file system will not be going into kernel 6.6, and its developer is not happy.
"It's taken some time to get KSMBD to a state that was considered stable," points out Linux magazine. That time has come, and KSMBD is planned for Linux kernel 6.6.: 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.
An announcement in 2021 had said that "For many cases the current userspace server choices were suboptimal either due to memory footprint, performance or difficulty integrating well with advanced Linux features."
LWN noted at the time that Linux has been using "the user-space Samba solution since shortly after the beginning." In a sense, ksmbd is not meant to compete with Samba; indeed, it has been developed in cooperation with the Samba project. It is, however, meant to be a more performant and focused solution than Samba is; at this point, Samba includes a great deal of functionality beyond simple file serving. Ksmbd claims significant performance improvements on a wide range of benchmarks...One other reason — which tends to be spoken rather more quietly — is that a new implementation can be licensed under GPLv2, while Samba is GPLv3.
The Register notes that when Samba switched to GPL 3, "one result was that Apple dropped Samba from Mac OS X and replaced it with its own, in-house server called SMBX." And they also remember that a month after its debut in 2021, "Linux sysadmins got to enjoy KSMBD's first security exploit." What's changed now is that it has faced considerable security testing and as a result it is no longer marked as experimental. It's been developed with the assistance of the Samba team, which itself documents how to use it. It's compatible with existing Samba configuration files. As the team says, "It is not meant to replace the existing Samba fileserver 'smbd', but rather be an extension and will integrate with Samba in the future...."
KSMBD is also important in that placing such core server functionality right inside the kernel represents a significant potential attack surface for crackers... The new bcachefs file system will not be going into kernel 6.6, and its developer is not happy.
"It's taken some time to get KSMBD to a state that was considered stable," points out Linux magazine. That time has come, and KSMBD is planned for Linux kernel 6.6.: 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.
SambaX was buggy and horrible (Score:5, Insightful)
Took Apple years to get SAMBAX usable when Samba was just fine. In fact I built it myself just to get around the many problems Apple's SMB server had. Hopefully they've got it working better these days. Their aversion to the GPL is a bit silly, really. But since their goal is to lock the machine down and prevent the owner from making any changes whatsoever to the root drive, I guess the GPL prevents that.
Re:[SMBX] was buggy and horrible (Score:2)
Ahem, I mean SMBX
Mod parent down! (Score:2, Funny)
Re: (Score:2)
Sadly slashdot is a shadow of its former self, and FP neither matters anymore, nor is it hard to get!
Comment removed (Score:5, Insightful)
Re: (Score:1)
But since their goal is to lock the machine down and prevent the owner from making any changes whatsoever to the root drive
It takes approximately two seconds to make changes to the root drive of MacOS if you're inclined to do so. The measures in place are there to harden and secure the environment, not to take away your freedom. You can step completely outside of the MacOS sandbox if you want to.
I guess the GPL prevents that.
Apple is hardly alone in having an aversion to GPLv3. Linus is on that hill himself.
Precisely.
Mods: Mod Parent Informative!
Re: (Score:2)
Samba isn't just fine. It's painful and unreliable.
Part of that is Microsoft's fault. Windows behaves a certain way, caching things in a way that isn't exposed through the protocol for example. Samba does things differently, and it causes all sorts of weird problems.
The other thing with Samba is that there are two ways to configure it. There is samba.cfg, but there is also a userspace config option.
Oh, and the lovely way that Samba users work. You have Samba users, Linux users, optional sync between them bu
Re: SambaX was buggy and horrible (Score:1)
Re: (Score:3)
My experience was more to do with SMBX crashing every time you looked at it, when Samba's smbd has run for me without such issues for many years. I forget it's there, but I can always access my files from windows. I've not delved into the black arts of Active Directory compatibility on Samba 4 and all the complexity that entails.
Re: (Score:2)
I've not delved into the black arts of Active Directory compatibility on Samba 4 and all the complexity that entails.
Assuming all you need is a single AD Domain Controller in a single domain, it works very well. One run of "samba-tool domain provision --use-rfc2307 --interactive" will create the domain controller, (assuming you have set up your hosts file before hand), and after that you simply set up either SSSD (Workstations) or Winbind (Workstations and SMB File Servers) on the domain members.
Samba AD is managed through Microsoft's own RSAT tools, so if you are used to AD management in Windows, you'll be right at ho
Re:SambaX was buggy and horrible (Score:4, Informative)
Samba does implement DFS, I wrote lots of the code for it and updated it recently :-).
I think you mean it doesn't implement DFS replication in the same way that Windows does.
Re: (Score:3)
Samba is only configured one way, via the smb.conf file.
Runtime control can be done via smbcontrol, but the base config file is always smb.conf.
When using local uses passwords *must* be separate as the SMB protocol and Linux passwords use completely different crypto.
Of course if you want synchronised passwords just add the Linux machine into the Active Directory Domain using Samba's winbind and users and passwords are identical of course.
Re: (Score:2)
There are companies who do "pay for play" Samba development. You pay 'em and tell them what you want in Samba, and they'll write it and upstream it for you.
Might be more than you want to pay though.
Re: (Score:2)
Oh, and the lovely way that Samba users work. You have Samba users, Linux users, optional sync between them but with potentially separate passwords, and file permissions on top...
That's squarely the fault of Linux, and partially the POSIX standard. Specifically:
1) No support for ACLs. NFSv4 has them and is mostly bit for bit compatible with the ACLs used by Microsoft, but of course the Linux kernel refuses to implement it because it's not part of the POSIX standard. (Despite practically every other major POSIX with NFS implementing support...)
2) No support for Nested Groups. Again, this is something that isn't in the POSIX standard, but required if you want to be able to resolv
Re: (Score:2)
Pretty sure ACLs work with Samba under modern file systems like Ext4. They are stored under extended attributes. Of course some of them may not mean anything to Linux itself, due to how SMB user IDs are vs linux uids. Been a few years since I delved into that.
Re:SambaX was buggy and horrible (Score:4, Informative)
The issue was specifically GPLv3. It's also worth noting that Linus himself is not a fan of that updated license.
Re: (Score:2)
Linus certainly isn't a fan of it for Linux, IIRC he is concerned about what it would mean for continued adoption.
You know what would be cool? If Oracle made ZFS GPLv3. HahAHahahHa I kill me
Re: (Score:1)
And with that, we can finally ditch SMB1 and SMB2 - the only reason SMB1 is still around is because that's what was supported when Samba was GPLv2 - it only acquired SMB2 support after it went GPLv3.
Can you imagine that? Microsoft's had to maintain an insecure protocol because of the GPL. How many devices were stuck at SMB1 because of it.
With kSMBd, it all changes in that Linux devices are no lon
Re: (Score:3)
This is completely incorrect.
Microsoft do not concern themselves with what SMB versions Samba supports when considering maintenance. At all.
As it should be IMHO. We match current versions of Windows and only keep SMB1 around in an "off-by-default" state for customers who can't or won't update old Windows / DOS clients.
Re: (Score:2)
All the Mac's lockdown and security of the protected filesystems can be turned off with a simple "csrutil disable" from a recovery prompt. I do agree some things like activation after a DFU restore on a Mac can be bad, since it requires the Mac to check in with Apple and one to log in with their AppleID to pass activation if the Mac is activation locked, but that is more of a security feature and a benefit denial for a would-be thief.
Now, iOS/iPadOS/etc... I agree with the parent -- way too locked down, an
Re: (Score:2)
Took Apple years to get SAMBAX usable when Samba was just fine. In fact I built it myself just to get around the many problems Apple's SMB server had. Hopefully they've got it working better these days. Their aversion to the GPL is a bit silly, really. But since their goal is to lock the machine down and prevent the owner from making any changes whatsoever to the root drive, I guess the GPL prevents that.
Apple has an aversion to GPLv3, a sentiment shared by many.
Keep the kernel from popping (Score:3)
Re:Keep the kernel from popping (Score:4, Insightful)
Re: (Score:1, Insightful)
SMB only matters because Windows. Linux shouldn't be encouragnig that.
Re: (Score:2)
Samba with an the iouring backend is as performant as an in-kernel version.
See Metze's talk this week at SNIA SDC 2023 in Freemont, CA. for details:
https://storagedeveloper.org/e... [storagedeveloper.org]
Re: (Score:1)
Re: (Score:3, Insightful)
Maybe they were trying to get this pushed out before Poettering's inevitable sambad reared its ugly head.
Re: (Score:1)
Maybe they were trying to get this pushed out before Poettering's inevitable sambad reared its ugly head.
You just know he really, really wants to...
Re: (Score:1)
Re: (Score:3)
In theory there are ways to isolate services sufficiently even in kernel space. Lots have been described, PCID based isolation such as in SeL4, LXD, vmfunc based isolation, language based isolation.
In practice though "code review will fix it". So don't have it loaded/compiled, or just run it as a pure Samba server.
Re: (Score:2)
Re: How about fix all the regressions?! (Score:3, Interesting)
Audio has been flaky on linux since Alsa supplanted opensound. The latter while clunky with a poor ioctl based interface and iirc only 1 process could access at a time at least did work consistently. Alsa never worked the same on 2 machines IME trying to use its C API to write sound for games back in the day. Then it got worse with pulse and gods knows what contorted software horrors there are now just to shove pcm data to a DAC.
Re: (Score:2)
Re: (Score:2)
Then it got worse with pulse and gods knows what contorted software horrors there are now just to shove pcm data to a DAC.
If you're shoving PCM data into a DAC then you're writing an audio subsystem for a 1998 use case, not a modern one. By all means if you use a computer like that more power to you, but modern people expect modern desktops to dynamically handle instantaneous switching between multiple audio inputs and outputs as they become available on the system, via driver interfaces that don't present as a DAC, require specialised codecs, clock control, or better still would not function if presented PCM data in the first
Re: How about fix all the regressions?! (Score:2)
Everything you mentioned is high level. PCM data is what the vast majority if audio cards use at the metal.
Re: (Score:2)
> The latter while clunky with a poor ioctl based interface and iirc only 1 process could access at a time at least did work consistently.
The one process limit was a flaw in the Linux implementation.
For example FreeBSD still uses it and it does not have an issue with multiple programs with sound and has not for a hell of a long time.
Re: (Score:2)
Then it got worse with pulse and gods knows what contorted software horrors there are now just to shove pcm data to a DAC.
This is so true and endlessly frustrating. I've been on Linux for a very long time, and out of general principle am willing to accept the odd quirk and to put in some extra effort to get things to work properly.
There are occasions though where I waver and just want to give up, buy a Windows license and be done with it. Sound is one such sore spot. When, in 2023, there's no way to get a pair of fucking bluetooth headphones to work properly with a bog standard computer (AFTER they'd already worked just fine
Fuck off (Score:3)
Genocide level kill SMB in all its disguises with fire.
Re: (Score:2)
RFC 7862 FTW.
Unfortunately, some shit home IoT want SMB1.0 (stereo receiver and VLC for Android TV). Fuck. I run 50 TiB on Samba to Mac w/ TimeMachine, Linux, Windows, Android, (stereo receiver), and Android TV. The issue is getting all of the damn options just right to work with all the things. NFSv4 doesn't just work on mac or Windows, so it's impractical as a viable solution.
Drug Against War... (Score:2)
...is my favorite KSMBD song
Kurt-Sune Med Berit (Score:1)
I wonder if Linus Thorvalds listen to the Swedish punk band KSMB [wikipedia.org].
(Swedish is Linus' mother tongue)
Re: (Score:2)
Kill Mother Fucking Block Daemon?! lol god damn you! Stronger than never ever before!