“Too Many Pointless Things”: Torvalds Rejects TSEM Module, Sparking a Linux Security Civil War
Ddos 
A fresh dispute has flared up within the Linux kernel developer community over security modules. The trigger was an appeal from one contributor who revisited a proposal made three years ago for a module called TSEM, intended to implement a universal security model. Despite the time that has passed, the code has yet to be accepted into the mainline kernel and, according to its author, has received little to no substantive review.
The absence of clear guidelines for introducing new security modules prompted the author to seek clarification from kernel developers and from Linus Torvalds himself. It was also stated that, should progress remain stalled, the matter could be escalated to the Linux Foundation’s Technical Advisory Board.
In response, Torvalds expressed open frustration with the situation, arguing that the sheer number of such initiatives has long exceeded reasonable limits. In his view, developers’ attempts to build bespoke solutions only add to the chaos of the ecosystem while delivering few tangible benefits.
Torvalds emphasized that new ideas must be developed collaboratively with the maintainers of existing subsystems, rather than bypassing established processes. In particular, he remarked that if the authors had failed to convince those responsible for the security module subsystem of their work’s value, they were unlikely to persuade him either.
The kernel developer further noted that the very notion of maintaining numerous distinct security models within the kernel has become a liability rather than an advantage. Divergent approaches, he argued, complicate maintenance and hinder long-term development. Instead of continually inventing new security architectures, the community should focus on improving the ones already in place, rather than insisting that each new proposal must inevitably surpass its predecessors.
Following Torvalds’ sharp rebuke, a counterproposal emerged: to formally prohibit the addition of new security modules altogether. Its proponent cautioned, however, that the community must remain receptive to technological innovation, lest Linux follow the path of commercial Unix systems that fragmented into incompatible variants under the influence of corporate interests. This side of the debate has likewise signaled its willingness to push for discussion at the Technical Advisory Board level.
The escalation of the conflict has cast renewed light on a long-standing and unresolved issue within the Linux ecosystem—the lack of clear, agreed-upon rules for introducing new security mechanisms. With each developer holding a different vision of what an ideal solution should look like, tensions remain high, and the debate may soon continue in a more formalized forum.
Donate