New NDS32 Port

New Linux ports come and go. Ideally, Linux will run on any piece of hardware that needs it, but some ports lose all their users and are eventually expunged from the kernel, while new hardware might come along, clamoring for a port in the kernel tree, and Linus Torvalds will say no because no one uses that hardware.

This time a promising port appeared on the Linux Kernel Mailing List for the NDS32 architecture. Greentime Hu posted patches that would successfully boot the hardware and would also pass "most LTP-2017 test suites in [the] NDS32 AE3XX platform." Arnd Bergmann liked Greentime's code and approved it for inclusion in the tree, and when Linus asked for some clarity on what the chip was actually for, Arnd said it was a plain low-end RISC architecture, generally used for systems-on-chip (SoC) products, and sat in the same category as ARM32, ARC, MIPS32, RISC-V, and Xtensa architectures.

Greentime added that billions of products had already shipped with his company's hardware, and their customers would get better Linux support if the code were in the main-line tree. In a situation like this, with support from Arnd, a recognizable set of similar chips, and many existing users, a port is likely to go quickly into the kernel, even if – as in this case – the code still barely runs on the hardware. In many other instances, code must be relatively spotless to make it into the tree, but for a port that is unlikely to have any effect on other parts of the kernel, even broken code is often acceptable at first.

Landlock Versus seccomp

Security debates are the hairiest. They often seem to come out of nowhere, and if you lose the debate, your patch is dead. It's not like other situations, where there are a clear set of interested parties and maybe your feature will have to be changed, but at least your use case will probably end up supported in some fashion. With security issues, you might have a perfectly valid need, and it will simply never be met.

MickaÎl Sala¸n posted a patch for Landlock recently that ran into some trouble. The Landlock security module draws a hard line between a given process and the rest of the system. Even a completely compromised process, if it's landlocked, can't escape to infect the rest of the system. The dream is for user processes to landlock themselves, and then, presto, there is no possibility of a security problem.

But there are circumstances – maybe obviously so – where landlocked processes might want to communicate with each other. MickaÎl's patch would set up a tightly constrained handshaking mechanism to allow landlocked processes to access each other under certain circumstances. For example, one process might debug another. Without any possibility of interprocess communication, this would remain impossible.

But Andy Lutomirski felt that these patches, and perhaps the entire Landlock module, were redundant with the seccomp security module. Instead of implementing a whole new set of security features, he argued, MickaÎl should focus his efforts on coding these same features for seccomp. Although seccomp was originally intended to block system calls, Andy indicated he was open to Landlock-esque extensions.

However, MickaÎl pointed out that his was actually the more sophisticated project. As he put it, "Landlock is more complex than seccomp, because of its different goal. seccomp is less restrictive, because it is more simple."

It did no good. Whatever argument MickaÎl made in favor of Landlock – for example adding easy sandboxes to larger applications or creating whole sandbox managers – Andy simply said that if these features were useful, they would be useful as additions to seccomp. As Andy put it, seccomp was already a living project engaged in exactly this sort of thing, and it would be wasteful to duplicate the effort and care going into it. MickaÎl did agree that his Landlock features would be valuable for seccomp, though he still wanted to keep the projects separate.

It's rough when the gatekeeper for your patch wants you to refocus your efforts on their own pet project, but such things have happened before, and to some extent, that's the way it's supposed to be. Redundant work does need to be identified and its efforts redirected more productively. Sometimes this means a developer must redo many hours of work and accept design decisions and implementation assumptions that they disagree with.

Sometimes developers can disagree so strongly that they will maintain their own alternative for years without backing down. In the late 1990s, Richard Gooch maintained his Devfs project for years against staunch opposition from Greg Kroah-Hartman, who favored the udev project. Eventually the udev project won out, but not before years of flame wars and bitterness were logged forever in the mailing list archives.

New Features from Intel

Intel is not sitting still. While the rest of us suffer slowdowns and security risks because of their longstanding hardware flaws, they are hard at work trying to address those flaws and rebuild their reputation, which is currently a slippery mess on the soles of everybody's shoes.

Reinette Chatre recently posted some patches to support Cache Allocation Technology (CAT). However she couldn't get out of her own way trying to explain the use and value of those features while maintaining deniability regarding whether the technology would exist in future processors.

The upshot of CAT is that it lets users constrain the amount of cache available to a given process. But Thomas Gleixner wanted to know if the feature would still be available in future chips, and if not, what that would mean for applications that relied on it. Would cached data become unavailable to those processes? All Reinette could answer was that the feature was "model specific." Gavin Hindman, also of Intel, tried at one point to clarify, saying that they couldn't guarantee the feature would exist in future chips, although they would like it to.

Thomas really wanted a little more than this, though. If the feature would simply disappear in the future, it might not be worth shoving code into the kernel that would only help a small number of aging systems.

Gavin explained that the future of the patch – and the hardware feature – partly depended on whether the kernel would support it or not. If yes, it might gain more users, and Intel might be inclined to build more chips with that feature. As Gavin put it, "We are in a bit of chicken/egg [situation] where people aren't broadly using it because it's not architectural, and it's not architectural because people aren't broadly using it." Or as Thomas paraphrased, "what you are saying is that 'official' support should broaden the user base, which in turn might push it into the architectural realm."

Ultimately, the question of this and other patches will be decided on a case-by-case basis. Regardless of its damaged reputation, Intel's chips are still absolutely everywhere, and Linux needs to support them. It's good that Intel is posting patches, and it's good that their patches are being considered, but there will likely continue to be a significant amount of tension between the kernel developers and Intel, at least until Intel reveals its ultimate intentions regarding fixing some of its glaring hardware problems. Those intentions can only be revealed as new generations of CPUs roll off the assembly line. It'll be years.