Linux overlord Linus Torvalds has offered some very choice words about different approaches security, during a discussion about whitelisting features proposed for version 4.15 of the Linux kernel.
Torvalds' ire was directed at open software aficionado and member of Google's Pixel security team Kees Cook, who he has previously accused of idiocy.
Cook earned this round of shoutiness after he posted a request to “Please pull these hardened usercopy changes for v4.15-rc1.”
Linus Torvalds pens vintage 'f*cking' rant at kernel dev's 'utter BS'READ MORE
“This significantly narrows the areas of memory that can be copied to/from userspace in the face of usercopy bugs by adding explicit whitelisting for slab cache regions,” he explained. “This has lived in -next for quite some time without major problems, but there were some late-discovered missing whitelists, so a fallback mode was added just to make sure we don't break anything. I expect to remove the fallback mode in a release or two.”
Torvalds' response expressed his doubts that Kees' contribution would be useful or had been well-tested. He therefore said “This merge window is not going to be one where I can take a leisurely look at something like this.”
Cook offered further explanation about his code, including “This is why I introduced the fallback mode: with both kvm and sctp (ipv6) not noticed until late in the development cycle, I became much less satisfied it had gotten sufficient testing.”
Torvalds then exploded.
“So honestly, this is the kind of completely unacceptable 'security person' behavior that we had with the original user access hardening too, and made that much more painful than it ever should have been,” he opened.
“IT IS NOT ACCEPTABLE when security people set magical new rules, and then make the kernel panic when those new rules are violated.”
That was just Torvalds warming up, as next came “That is pure and utter bullshit. We've had more than a quarter century _without_ those rules, you don't then suddenly walz [sic] in and say 'oh, everbody [sic] must do this, and if you haven't, we will kill the kernel'.”
“The fact that you 'introduced the fallback mode' late in that series just shows HOW INCREDIBLY BROKEN the series started out.”
Torvalds post explained his attitude to security, namely that “security problems are just bugs” rather than opportunities to change the way the kernel behaves.
“The important part about 'just bugs' is that you need to understand that the patches you then introduce for things like hardening are primarly [sic] for DEBUGGING.”
“I'm not at all interested in killing processes. The only process I'm interested in is the _development_ process, where we find bugs and fix them.”
“As long as you see your hardening efforts primarily as a 'let me kill the machine/process on bad behavior', I will stop taking those shit patches.”
“Some security people have scoffed at me when I say that security problems are primarily 'just bugs'.”
“Those security people are f*cking morons.”
He added that “I think the hardening project needs to really take a good look at itself in the mirror” and abandon a “kill on sight, ask questions later” mentality in favour of the following approach:
Let's warn about what looks dangerous, and maybe in a _year_ when we've warned for a long time, and we are confident that we've actually caught all the normal cases, _then_ we can start taking more drastic measures
Torvalds has long been unafraid to express himself in whatever language he chooses on the kernel and has earned criticism for allowing it to become a toxic workplace. He's shrugged off those accusations with an argument that his strong language is not personal, as he is defending Linux rather than criticising individuals.
On this occasion his strong language is directed at a team and Cook's approach to security, rather than directly at Cook himself. It's still a nasty lot of language to have directed at anyone.
Cook has copped it in style, having posted that “I think my main flaw in helping bring these defenses to the kernel has been thinking they can be fully tested during a single development cycle, and this mistake was made quite clear this cycle, which is why I adjusted the series like I did.”
He concluded by saying “I'd like to think I did learn something, since I fixed up this series _before_ you yelled at me. :)”
“I'll make further adjustments and try again for v4.16.” ®