Teardown of a Failed Linux LTS Spectre Fix

You can only have so much process before you're too far out of the bazaar. This isn't to bring up the relative value tradeoffs of that old split, just to highlight that one shouldn't expect a 'process adjustment' reaction from a fundamentally anti-process collective or for members to even view it primarily through the lens of a process failure. (I'd sooner expect a rant on basic C coding competence even though those days are gone.) That's even if the LKML reflects on this particular timeline of patches much at all; there's no good reason to, really, it's a curiosity. And unlike those of us in a proprietary enterprise no one expects or can insist on an RCA doc with promises to do better backed by planned process tweaks (what issues can't ultimately be recast as process failures?) or new processes.

That's what I was thinking too. Extra diff changes in a merge commit is often hard to notice

Indeed, this is called an "evil merge" [1], and here's [2] even an email with Linus mentioning it. I'm surprised the blog post doesn't mention evil merges by name, as this seems to be a prime example of why they're called evil.

[1]: https://git-scm.com/docs/gitglossary#Documentation/gitglossa...

[2]: https://www.mail-archive.com/git@vger.kernel.org/msg73938.ht...

Because a significant portion of those changes will conflict, and one will have to go back to each commit that made the changes to figure out the intention of the change.

Easier to back port each set of changes while knowing what the point of the changes are.

Patches have to be in Linus's tree before they land in -stable. That's been the policy for at least as long as I remember. Also, Greg does releases of -stable every week or two -- waiting 8 weeks for patches (that Linus has already merged) makes very little sense.

Yes, fixup patches are something that need to be handled separately but Greg has always handled those properly (and good kernel devs use the Fixes: tags and always Cc: stable on those fixup patches). Not to mention you'd need to handle fixup patches even if you did depend on releases (if a bug was introduced in a released version it's usually fixed by the next -rc1 -- so waiting means the newest kernel is broken needlessly for 8 weeks).

How would you back-port from a release, apart from cherry-picking commits or patch-sets?

Redhat distributes it's sources to everyone, thus making any violation of the no-restrictions-on-redistribution clause acedemic to the linux copyright holders who would be the claimants.

GRSecurity successfully prevents redistribution: it's violation is blatant and NOT academic.

A court can be shown the attempt and it's successful conclusion.

Quite different in substance from RedHat's possible violation.

That is not a "work around". That is a BLATANT in-writing VIOLATION of the no-restrictions-on-redistribution clause GRSecurity MUST follow in-order to have the PERMISSION to create derivative works.

GRSecurity IS violating the copyrights of the linux copyright holders upon whom it's derivative work is derived from.

BLATANTLY. In Writing.

Perens is correct. Perens' lawyers are correct.

C++ is broken without exceptions. Exceptions aren't ever going to enter the kernel even if you tried to hide them behind a C ABI.

In this case the author is right, so your guy's faults do not figure. Stern, opinionated, and wrong are obviously worse than just wrong.

So one could argue that Linus kinda failed in fixing the problem he has identified correctly.

Actually, you missed the point of everything.

> I was not talking about the article's author

First. I said "the author's intention is criticizing the ad-hoc, error-prone approach" on fixing Spectre vulnerabilities. Please consider what did I really mean. I meant: It is believed that this type of mistake is inevitable, regardless of who writes the code, in the end, a mistake like this one will be made, and probably have already been made, much earlier than the reported one, and still undetected. If you get this message, "who did it" becomes a unimportant question.

Second, it's not some 0day fixes, but a Spectre fix, precisely, a Spectre variant 1 fix. This distinction is important - everything today is still largely vulnerable to Spectre to an extent, and this situation is unlikely to change. For Spectre v1, the outcome is a simple infoleak, among all Spectre vulnerabilities, its risk considered relatively low.

The current Linux kernel's approach to Spectre v1 is plugging them one by one. As the Linux kernel documentation explains,

> Vulnerable code uses nospec accessor macros for "bounds clipping", to avoid any usable disclosure gadgets. However, this may not cover all variant 1 attack vectors.

It means a lot of potential Spectre v1 vulnerability already exist in the kernel (and elsewhere), but they're probably not too useful for the attack without another exploit.

Third, the defective patch does not introduce any vulnerability. The original code was a potential Spectre v1 exploit gadget, and a Chinese developer noticed that in a code review, and submitted a patch to fix it. However, the patch generated a compiler-warning. Linus Torvalds fixed it, but it evaded the detection from maintainers, and finally a broken version created by the stable kernel maintainers got merged into all stable trees.

And let's assess the situation.

1. More than one potential Spectre v1 vulnerability gadgets already exist in the kernel, regardless of anyone's actions. It means all the deployed production systems all across the Internet are already somewhat vulnerable.

2. In the kernel ptrace code, there was a Spectre gadget. Again, it means all the deployed production systems all across the Internet are already vulnerable to it.

3. A Chinese developer submitted a "fix". Linus noticed the fix was broken, but the kernel maintainers picked up the old patch.

4. As a result, (1) no new fix is introduced, no new bug is introduced, (2) all the deployed production systems all across the Internet are still vulnerable to the same Spectre gadget, just like before. And (3) the head of a infosec company noticed it and published an article to criticize the mainline kernel. (4) It created a lot of buzz and the problem is fixed. There is nothing even remotely close to "the entire avalanche in the code repository", the code repository worked exactly like before.

In conclusion, we ask, cui bono - "to whom is it a benefit?".

If I was the security service of the Chinese government, my intention could never be inserting a malicious vulnerability, because the same type of vulnerability already existed, I probably know a lot of different ones as well. Further, even if the gadget in ptrace is the only vulnerability I know, by submitting a false fix, it did not introduce any additional vulnerability, but in fact greatly increased the chance of the fix being noticed and fixed. I gained nothing by going through all of these troubles by first creating a good patch which generates a compiler warning to trick maintainers to ruin the patch while attempting to fix it.

So we can rule out the "Chinese hacker" meme, it doesn't make sense at all. If you still insist, the only possibilities remained are,

1. The intention of the attacker by submitting a false fix is to mislead the kernel developers to believe the fix is good. So that nobody would notice the same problem in the future, so that I can use it as a long-term backdoor, not only a short-term one.

Certainly possible, but unlikely. By submitting the code, the risk of being discovered is much higher than the benefit of keeping the original vulnerability undetected, because it generates a compiler warning. Even worse, regardless of the compiler warning is being noticed or not, in either way, I ended up risking to patch my own backdoor. Not to say the original vulnerability is something of little value.

2. The intention of the attacker by submitting a false fix is to start a propaganda campaign and discredit the competence of kernel developers. Or to examine the abilities of kernel maintainers to avoid making mistake, or some other grand scheme of chess.

If I am the project leader of a Chinese operating system, perhaps I'd like to do this, as it would be beneficial to me for citing it as my evidence later to push my project's agenda. Another scenario would be that the author of the article and his infosec company has connection to the Chinese government, so he asked the Chinese security service to do an inside job, and he would expose it later to increase the sales of grsecurity.

Again, certainly possible, but unlikely, and very stupid.

In conclusion, if you cannot understand even the basic facts (such as the nature of Spectre vulnerability), fail to comprehend the basic idea of an simple article like this one, and fail to understand the comments, I suggest you to stop posting uninformed comments.

Or that the author of the article and his infosec company has connection to the Chinese government, so he asked the Chinese security service to do an inside job, and he would expose it later to increase the sales of grsecurity, which in turns support the secret service...

It is one of the only few logical conclusions one can draw if one insists on OP's opinion that the Chinese attackers are playing 4D chess. The chance is non-zero, but doesn't make much sense.

Ah yes, you're quite right, this is legal C99 and C11, but not legal C90.

I'm more of a C++ programmer, and the C code I deal with tends to be ancient, so I had forgotten that this became legal at some point.