The author's intention is criticizing the ad-hoc, error-prone approach on fixing Spectre vulnerabilities. It said,
> When the upstream kernels later backported their bad fix, it created a conflict in our git repo that led to us immediately spotting their flaw (and keeping our existing fixes). But what if we hadn't backported the fix, or what if the issue was one of the many other Spectre instances lurking in the kernel?
I bet for 100 dollars, that at least another unfixed Spectre vulnerability already exists in the kernel, the Chinese government has no reason to waste energy on inserting a broken fix.
Note: The author talks about the private complier solution of his company at the end of the article (unfortunately, on one hand, the author is well-known for developing various unique security solutions, on the other hand the hostile relation between the author and the mainline kernel community is well-known, it's unfortunately that no other independent developers are working with mainline kernel community towards a similar solution).
Saving mention of the proprietary tool to the end showed restraint. That such failures are detectable by tooling is important information, even when not everybody has the tool. Maybe especially then.
Actually, you missed my point. I was not talking about the article's author, I was talking about the Chinese developer who "fixed" the code, that triggered the entire avalanche in the code repository.
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.
The author's intention is criticizing the ad-hoc, error-prone approach on fixing Spectre vulnerabilities. It said,
> When the upstream kernels later backported their bad fix, it created a conflict in our git repo that led to us immediately spotting their flaw (and keeping our existing fixes). But what if we hadn't backported the fix, or what if the issue was one of the many other Spectre instances lurking in the kernel?
I bet for 100 dollars, that at least another unfixed Spectre vulnerability already exists in the kernel, the Chinese government has no reason to waste energy on inserting a broken fix.
Note: The author talks about the private complier solution of his company at the end of the article (unfortunately, on one hand, the author is well-known for developing various unique security solutions, on the other hand the hostile relation between the author and the mainline kernel community is well-known, it's unfortunately that no other independent developers are working with mainline kernel community towards a similar solution).