Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Linux

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.
This discussion has been archived. No new comments can be posted.

KSMBD Finally Reaches 'Stable' State in Release Candidate for Linux Kernel 6.6

Comments Filter:
  • by caseih ( 160668 ) on Saturday September 16, 2023 @01:45PM (#63853516)

    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.

      • by Anonymous Coward
        You sacrifice accuracy in place of getting FP. That is shameful.
        • by caseih ( 160668 )

          Sadly slashdot is a shadow of its former self, and FP neither matters anymore, nor is it hard to get!

    • by Shakrai ( 717556 ) on Saturday September 16, 2023 @02:50PM (#63853600) Journal

      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.

      • 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!

    • by AmiMoJo ( 196126 )

      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

      • Just commenting on its longevity.....I guess it's just easier to imagine a presentation layer service and drop SMB on top rather than imagine how a service will integrate with the kernel? I once had a feeling that the 2.x kernels were SMB's last chance and Microsoft was to replace it completely.
      • by caseih ( 160668 )

        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.

        • 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

      • 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.

      • 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

        • by caseih ( 160668 )

          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.

    • by 93 Escort Wagon ( 326346 ) on Saturday September 16, 2023 @03:19PM (#63853634)

      The issue was specifically GPLv3. It's also worth noting that Linus himself is not a fan of that updated license.

      • 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

      • by tlhIngan ( 30335 )

        The issue was specifically GPLv3. It's also worth noting that Linus himself is not a fan of that updated license.

        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

        • 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.

    • 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

    • 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.

  • by dotslashdot ( 694478 ) on Saturday September 16, 2023 @01:49PM (#63853522)
    I think itâ(TM)s a bad idea especially from a security standpoint to add smb to the kernel. It already ran fine in user space. Based on this logic, why not just load everything into the kernel? That will turn the kernel into popcorn.
    • by billyswong ( 1858858 ) on Saturday September 16, 2023 @02:06PM (#63853558)
      Linux is since the beginning a monolithic design. The motivation behind a kernel version of SMB server as I heard is about those poor NAS and other embedded devices, squeezing their last drop of performance. I guess those vendor treasure speed over security, and many of their users are in the same mindset.
      • Re: (Score:1, Insightful)

        by Anonymous Coward

        SMB only matters because Windows. Linux shouldn't be encouragnig that.

      • 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]

        • Sigh. Megacorps have engineers who need job security, so they "donate" their "white elephants" so they can maintain them and bump their performance reviews.
    • Re: (Score:3, Insightful)

      Maybe they were trying to get this pushed out before Poettering's inevitable sambad reared its ugly head.

      • 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...

      • systemd, pulseaudio, emacs, and gcc-toolchain in the kernel. The reasoning will be "BuT iT's fAsTeR aNd SiMpLeR." Me: ....
    • 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.

    • Agreed. Kernel shouldn't be a dumping ground for parts of applications if they don't need to be there. Hell, the monolithic kernel model and the massive number of features and drivers are inherently unsafe too. There ought to be an effort to write a formally-verified, capabilities-based, cross-module transaction coordination, zero-copy message passing microkernel that's mostly Linux userland and syscall compatible in say Rust.
  • by backslashdot ( 95548 ) on Saturday September 16, 2023 @08:50PM (#63854134)

    Genocide level kill SMB in all its disguises with fire.

    • 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.

  • ...is my favorite KSMBD song

God doesn't play dice. -- Albert Einstein

Working...