Tweet
Originally posted by Steffo
View Post
-
In theory you are right. In practice it has long been pretty common on all OSes. -
no its not nfs is in the kernel for over a decade ....Originally posted by Steffo View PostComment
-
Right. nfsd is the kernel level component with a user space one as well.Originally posted by gorgone View Post
ksmbd = kernel level component, ksmbd-utils = user space stuff.
honestly this is just an easier nfs that doesn't require as much configuration. ksmbd has already been in use with OpenWrt. Much faster than Samba on low end routers.Comment
-
One of the plans for KSMBD is support for RDMA and, presumably, SMB Multichannel and SMB Direct. SMB Direct can basically give you lower latency and higher throughput while using less CPU when serving files. The idea is that it's substantially simpler to implement these things inside the kernel space than it is from user space. Which doesn't sound like hot air, given the DMA in RDMA. It's not like people just wanted to make an in-kernel server for a minor improvement.
As far as security goes, complexity is worse than a new feature because it's harder to test and audit. And until the blessed GNU Hurd descends from the matrix to save us, some things have to be in the kernel. At least until we design and build good interfaces to move them out. But we only do that after the features are written because YAGNI. We don't preemptively design interfaces before we know why we need them (and thus what they'll be) or we'll just have to rewrite them.
Assuming you have a NIC capable of RDMA (which you can currently get for substantially less than $100 USD), this could make a huge impact on file servers. And while corporations will definitely benefit from the reduced resource usage/increased performance, I'd say individuals who can utilize this will also get a direct, appreciable gain. Given the limited budget most home users have, being able to squeeze a lot more out of a home server sounds really nice. Yes, not everyone runs an SMB server, but enough of us do that it's not like this runs contrary to individual interests. Lots of us, for example, run custom router firmware to do file shares on routers. They likely won't have RDMA hardware, but it does show that the SMB use case is actually pretty big if you've got more than one device in a household. And almost anybody running a DIY NAS is going to gain from this.
As with most kernel things, it can probably be disabled at compile or at boot. Just having the code isn't going to ruin security - especially if you're not running an SMB server. I expect the average desktop user will be completely unaffected by this, though I'm sure purists can collaborate to track kernel parameters and KConfig options they can use to streamline their system. It's best not to approach new features with an alarmist attitude - even if we don't personally understand or have the use case. I'd suggest following the article's link to the previous thread which talks a lot more about this.Comment
-
Not even hurd is going to save you here. If you actually care that much about security you should be using a formally verified kernel (such as sel4) which is actually being used for critical applications (defense, medical, even on the secure enclave in apple devices).Originally posted by Terrablit View Post
Micorkernel only gives you the segregation, you still need to prove that the segregation works (i.e. there are no leaks in the interface).Comment
-
A nice feature for file sharing with KVM Windows Guests - one less daemon to runComment
Comment