Is It a Bug or Is It Time to  Go?

Davyd McColl wanted to mount a really old Common Internet File System (CIFS) v1.0 drive but ran into a kernel bug that caused the mount to fail. He spent a few hours in Git bisecting the exact patch that caused the problem and posted his findings in the hope that a fix might be found.

CIFS is a variant of Server Message Block (SMB) introduced by Microsoft with Windows 95 in 1996. SMB in turn was developed by IBM in the 1980s. CIFS and SMB are used for sharing file repositories with other users on the same network.

This is old tech that has long since been replaced with much better options, but apparently CIFS 1.0 drives can still be found with data on them, and people like Davyd would still like to access that data. Davyd in particular remarked in his email, "Whilst I understand the desire to clean up code and remove dead branches, I'd really appreciate it if this particular feature remains available either by kernel configuration (which suits me fine, but is likely to be a hassle for anyone running a binary distribution) or via boot parameters."

There was some discussion on the Linux Kernel Mailing List, including efforts by folks such as Steve French and Ronnie Sahlberg to check Davyd's bug against possible bugs elsewhere in related code.

However, their discussion petered out after a while, prompting Thorsten Leemhuis – who often concerns himself with these types of regressions and other bug tracking – to ask, "Davyd, Ronnie, and/or Steve: What [is] the status here? It seems after some productive debugging back and forth it seems everyone forgot about this. Or was progress made somewhere and I just missed it?"

Davyd replied that he had most certainly not forgotten and was continuing to use a workaround to access his CIFS 1.0 drive. He also was checking each kernel release to see if the issue had been resolved. In addition, Ronnie remarked, "I tried but can not find a system old enough to reproduce. Remember, this is an authentication mechanism that Microsoft begged people to stop using and migrate away from over 20 years ago. [...] there is just so much time you can spend on something that was declared obsolete 20 years ago."

Thorsten replied that in that case, maybe the best solution would be to simply revert the patch Davyd had found to be the cause of the problem. To which Ronnie replied, "Right now you can likely just revert it. Maybe in the next kernel too. But in a kernel not too far into the future some of the crypto primitives that this depended on will simply not exist any more in the linux kernel and will not be available through the standard api. At that point it is no longer a matter of just reverting the patch but a matter of re-importing an equivalent crypto replacement and port cifs.ko to its new api."

Thorsten felt he needed some guidance from above. He said:

"I pointed Linus towards this thread two times now, but he didn't comment on it afaics. CCing him now, maybe that will to the trick. If not, it'll leave me with two options:

a) give up

b) submit a revert for 5.18 to force a discussion of the issue

"I currently tend to do the latter due to the fact that it's something that still works on Win11 with a simple change in the registry."

But in fact, Linus Torvalds did reply, saying:

"I have to admit that I think it's a 20+ year old legacy and insecure protocol that nobody should be using.

"When the maintainer can't really even test it, and it really has been deprecated that long, I get the feeling that somebody who wants it to be maintained will need to do that job himself.

"This seems to be a _very_ niche thing, possibly legacy museum style equipment, and maybe using an older kernel ends up being the answer if nobody steps up and maintains it as an external patch."

Steve replied, "We have been looking to see if we could setup some VMs for something that old, and we are willing to test against it if it could realistically be setup, but it has been harder than expected. [...] realistically it is very hard to deal with 'legacy museum style' unless we have some VMs available for old systems."

Thorsten also replied, saying that he was "not sure if 'museum style equipment' really applies here, as the hardware seems to be sold in 2013/2014 and according to the reporter even got a update in 2016. But whatever, yes, it's niche thing and what the hw [hardware] manufacturer did there was a bad idea. Anyway, I'll stop tracking this then."

And that was the end of the discussion.

Personally, the thing I find fascinating about this is that Linus generally is extremely reluctant to remove support for any hardware that may still be in use. Even a single user of a kernel feature can be enough to ensure it will stay in the kernel. So the question is always, when a feature does get removed, what are the circumstances? And, in this case, it seems that one part of the threshold for staying in the kernel tree is that someone who actually cares about that hardware or that protocol needs to be willing to maintain the code that supports it. But also, I think Linus regards CIFS 1.0 as fundamentally vulnerable to security attacks and as something that even the company who designed the protocol doesn't want anyone to use. So in that kind of situation, having active users of a kernel feature may not be enough to justify keeping it once it starts to break down.

Out, Out, a.out!

A while back, Borislav Petkov posted a patch to deprecate a.out support in Linux on the x86 architecture. a.out is the original format of the Linux compiled binary and other executable binaries, which has since been replaced by ELF. Since Borislav's patch, several kernel versions came out without complaint, so he posted another patch to actually remove a.out support from Linux.

There was general cheering, exultation, and wistful reminiscence of the good old days of Minix and AT&T UNIX. There was also quite a bit of eager talk of ripping out a pile of system calls that would no longer be needed if a.out were going away. Several folks also discussed with fluttery tummies the possibility of removing a.out support on other architectures. Linus Torvalds supported the whole plan as well, remarking with dour optimism, "note: there are similar other turds if a.out goes away, ie on alpha it's OSF4_COMPAT, and it enables support for a couple of legacy OSF/1 system calls."

A while later, in a new discussion thread, Eric W. Biederman continued this work, this time on the Alpha and m68k architectures, saying, "There has been repeated discussion on removing a.out support, [and] it looks like no one has see any reason why we need to keep a.out support. The m68k maintainer has even come out in favor of removing a.out support. At a practical level with only two rarely used architectures building a.out support, it gets increasingly hard to test and to care about. Which means the code will almost certainly bit-rot."

To test his theory that no one really cared, Eric posted a patch to disable a.out by default in the build system. Of course, anyone could re-enable it by hand when building the kernel, so he felt his patch would be sure to raise whatever eyebrows needed to be raised on this question. In which case, he concluded, "we can then have a discussion about what it is going to take to support a.out binaries in the long term."

However, Linus raised his eyebrows – in spite of his general support of eradicating a.out in the kernel – and replied:

"Oh, I'm pretty sure we can't do this.

"a.out on alpha is afaik still very much alive – well, as alive as anything alpha is – although it's called 'ECOFF'.

"It's the native Tru64 (aka 'DEC OSF/1', aka 'Digital UNIX') format, so it's more than some old legacy Linux thing.

"We still call it 'a.out', but the history is that a.out with some extensions became COFF, which then became ECOFF, so our a.out code really covers the whole gamut.

"Yeah, we don't actually parse any of the extensions that make COFF what it is, or ECOFF what _it_ is, but the a.out loader ends up working 'well enough' for simple binaries by using ugly code [...].

"But sure, it would be interesting to know if any alpha people care – I just have this suspicion that we can't drop it that easily because of the non-Linux legacy."

Kees Cook replied, "It looks like the only distro supporting Alpha is Gentoo. I pulled down the installation media, and everything is ELF except for firmware COFF files." Kees concluded, "So, since it's an easy revert, sure. Let's do it."

And that was that.

So a.out is coming out of Linux, after all this time. It's always fascinating to see the way the Linux kernel persists as a living project, avoiding the bloat and pointlessness that afflict a lot of other software projects. After 30 years and billions of users, one might expect Linux to become weighted down by all sorts of nightmare requirements and psychotic contradictions, but it doesn't happen. Linux continues to support the world's entire infrastructure in all its diversity, while simultaneously sloughing off dead skin and rejuvenating its own inner organs in a perpetual mission of universal love (it's true).

GitHub Support for Git

Max Filippov posted a pull request for Linus Torvalds, using a repository hosted on GitHub. In the course of making that request, Max remarked, "I've noticed that github removed support for the unauthenticated git:// protocol. Should I send pull request URLs using ssh or https?"

Linus replied:

"I suspect for consistency, using https:// is the way to go.

"I'm a bit sad to see 'git:' go, since that was visually such a good marker that it's about a _git_ server, not some random web page (and I rely on the signed tag, not on some https thing).

"But from a technical angle, I guess it was inevitable. And git is everywhere, and 'github' certainly makes that 'it's a git repo' part obvious anyway, so."

And that was it – a very short discussion. The reason I'm covering it here is that it's sort of ironic. Microsoft was always the Great Beast in the early and middle days of Linux, doing everything it could to destroy the entire project and push its own operating system, even onto unwilling users. Then, after Linus also created the Git version control system, Microsoft bought the biggest Git hosting service and has now removed that same git: protocol as one of the available ways to pull a repository.

It doesn't seem as though Linus is all that bothered by it, so it's probably not much of a big deal, beyond the whole "don't forget that Microsoft doesn't really love open source" concept.