On Wed, Sep 13, 2023 at 10:03:55AM -0700, Linus Torvalds wrote: > On Wed, 13 Sept 2023 at 09:52, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > > > > Isn't it more typical to mark something as on its way to deprecation in > > Kconfig and/or a printk? > > I haven't actually heard a good reason to really stop supporting > these. Using some kind of user-space library is ridiculous. It's *way* > more effort than just keeping them in the kernel. So anybody who says > "just move them to user space" is just making things up. No filesystem developer thinks that doing a whole lot of work to move unmaintained, untestable fs code from the kernel to an unmaintained, untestable (and likely broken) fs library in userspace is a viable solution to any of the problems being discussed. There's a whole lot more to this discussion than "what to do with old, unmaintained filesystem code". > The reasons I have heard are: > > - security > > Yes, don't enable them, and if you enable them, don't auto-mount them > on hot-pkug devices. Simple. People in this thread have already > pointed to the user-space support for it happening. This is just a band-aid. It does nothing to prevent kernel compromise and is simply blame-shifting the inevitable kernel compromise to the user because they had to explicitly mount the filesystem. It's a "security theatre" solution at best. Indeed, it does not address the frequently requested container use cases where untrusted users (i.e. root in a container) need to mount filesystem images. This is a longstanding feature request we really need to solve and ignoring it for the purposes of knocking down a strawman really doesn't help us in any way. Put simply, what we really need is a trust model mechanism that allows all the kernel supported filesystems to be mounted by untrusted users without any risk that the kernel could be compromised by such an operation. That's where lklfuse comes into the picture: it allows running the kernel filesystem parsing code in an isolated userspace sandbox and only communicates with the kernel and applications via the FUSE interface. IOWs, we get *privilege separation* with this lklfuse mechanism for almost zero extra work on all sides of the fence. The dangerous stuff occurs in the sandboxed user process so the risk of kernel compromise is greatly minimised and the user and their applications can still access it like a normal kernel filesystem. And because it uses the kernel filesystem implementations, we don't have a separate codebase that we have to maintain - we get up-to-date filesystem implementations in userspace for free... To go back to your original concern about avoiding the removal of unmaintained filesystems, once we get a robust trust model mechanism like this in place we we can force them to be mounted through the supported privilege separation mechanism. Then they can't compromise the kernel, and the vast majority of the "untested, unmaintained code that parses untrusted data in kernel space" concerns go away entirely. IOWs, if we deal with the trust model issues in a robust manner, there is much less need for drastic action to protect the kernel and users from compromise via untestable, unmaintained filesystem code. Your argument for keeping them around indefinitely *gets stronger* by addresing the security problems they can expose properly. Hence arguing against improving the filesystem trust model architecture is actually providing an argument against your stated goal of keeping those old filesystems around for ever.... At this point, the only concern that remains is the burden keeping these old filesystems compiling properly as we we change internal APIs in future. That's another thing that has been brought up in this discussion, but.... > - "they use the buffer cache". > > Waah, waah, waah. .... you dismiss those concerns in the same way a 6 year old school yard bully taunts his suffering victims. Regardless of the merits of the observation you've made, the tone and content of this response is *completely unacceptable*. Please keep to technical arguments, Linus, because this sort of response has no merit what-so-ever. All it does is shut down the technical discussion because no-one wants to be the target of this sort of ugly abuse just for participating in a technical discussion. Given the number of top level maintainers that signed off on the CoC that are present in this forum, I had an expectation that this is a forum where bad behaviour is not tolerated at all. So I've waited a couple of days to see if anyone in a project leadership position is going to say something about this comment..... <silence> The deafening silence of tacit acceptance is far more damning than the high pitched squeal of Linus's childish taunts. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
