> The takeaways here are that there is a real benefit to having an external/independent review and backporting process like the one we perform for our customers<p>That's great for sales for these people, but I think the real takeaway here is:<p>> when the actual merge of the tree was performed, no mention was made of [Linus's] correction to the [original] fix, and with no specific commit mentioning the correction and fixing it alone, everyone else's processes that depended on cherry-picking specific commits ended up grabbing the bad warning-inducing change. As a further failure, instead of looking at Linus' correct fix (observable by checking out the master tree at the time), the approach employed in the LTS kernels seems to have been to naively silence the warning<p>There are a LOT of process failures in this description of what happened. At the kernel development level, that should be very concerning.<p>It's good that an external auditor found it (hooray open source), but this was almost definitely an easily preventable mistake with a better process.<p>> everyone else's processes that depended on cherry-picking specific commits<p>This alone sounds horrifying.<p>I don't know anything about kernel development, so I don't want to sit here and judge and offer advice out of ignorance, but I really do feel like there's a better process that would work for them that doesn't involve people "cherry-picking specific commits."
> Finally, it should be noted that the "many eyes" of the upstream community failed to notice this flaw; without this blog post it would have likely persisted for many years.<p>Such a spicy remark, this whole post is great. (Though "many eyes" typically refers to an oft-claimed quality of open source generally with no arbitrary distinctions of upstream / downstream. grsecurity makes up some of those valued eyes for Linux!)<p>This makes me wonder what other logic errors were introduced into the kernel because of an incorrect resolution to a warning...
It's wonderful of grsecurity to produce a review like this - it'll be extremely helpful in addressing any issues in the development and patch management process. One can only think what improvements we might see in regards to Linux security, as a whole, if they'd work more proactively with the rest of the community. Of course, they're under no obligation to do so.<p>Unfortunately, I doubt that we'll ever have their participation - or even see or review any of grsecurity's modifications - all because of grsecurity's "Access Agreement". [0] Essentially, if I understand it correctly, even if grsecurity's customers wanted to, by sharing grsecurity's work with us or anyone else, those customers stand to have their access to the latest grsecurity created derivatives of the Linux kernel revoked. Of course, if that's true, facing a penalty for sharing code grsecurity received and modified per the GPL just doesn't sound right or just to me.<p>It seems obvious to me that one must carefully consider the wider picture when evaluating linux security posture evaluations, as presented by grsecurity, as there may be conflicts of interest in effect. I take what grsecurity says about the security of the Linux Kernel with a very large grain of salt, and you should as well.<p>Further, I'm not a legal expert and I use measured tones as grsecurity have taken legal action against open source community members in the past for expressing their opinions [1] on the matter of the access agreement [2]. While those matters were dismissed by the court [3], I am still hesistant to say anything, but find speaking on this matter a neccessary thing to do, for what I perceive to be the good of the community.<p>[0] <a href="https://grsecurity.net/agree/agreement_faq.php" rel="nofollow">https://grsecurity.net/agree/agreement_faq.php</a><p>[1] <a href="https://perens.com/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/" rel="nofollow">https://perens.com/2017/06/28/warning-grsecurity-potential-c...</a><p>[2] <a href="https://www.theregister.co.uk/2017/08/03/linux_kernel_grsecurity_sues_bruce_perens_for_defamation/" rel="nofollow">https://www.theregister.co.uk/2017/08/03/linux_kernel_grsecu...</a><p>[3] <a href="https://perens.com/wp-content/uploads/sites/4/2017/12/file0.43502131597246.pdf" rel="nofollow">https://perens.com/wp-content/uploads/sites/4/2017/12/file0....</a>
C90 is partly to blame is here. It rejects sensible code due to limitations of hardware and compilers older than Linux itself.<p>I find it hard to believe that a decades old compiler with an actual compile-in-one-pass limitation would produce something useful from the current kernel source. It's affecting the the entire kernel development just so that someone somewhere with an abandonware compiler doesn't get a shock of updating it once every 30 years.
Man that attitude of the grsecurity folks is bad. Oh look how great our process and fix is and how fast we are. And look how bad them kernel folks are. Yuk.
GRSecurity is violating the GPL, and thus violating the linux programmers copyrights, as Bruce Perens explained:
<a href="https://linux.slashdot.org/story/17/07/09/188246/bruce-perens-warns-grsecurity-breaches-the-linux-kernels-gpl-license" rel="nofollow">https://linux.slashdot.org/story/17/07/09/188246/bruce-peren...</a><p><a href="http://perens.com/blog/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/" rel="nofollow">http://perens.com/blog/2017/06/28/warning-grsecurity-potenti...</a><p>Brad Spengler / PaxTeam / GRSecurity have no right to modify the linux code nor redistribute derivative works of it thusly.<p>Placing a "no redistribution or else" clause in a "separate writing" does not absolve one from the requirement NOT to stymie the linux programmer's stipulation in their license that such restrictions NOT be created by distributees or those who have created derivative works.<p>The linux programmers should sue Spengler, or simply revoke his license (another option: gratis licenses are freely revocable: they are not secured by an interest, and as-far-as-we-know Spengler has not payed the linux licensors for a license).
There was another post on this here: <a href="https://news.ycombinator.com/item?id=20871727" rel="nofollow">https://news.ycombinator.com/item?id=20871727</a> (10h ago, pointing to a short excerpt on lwn.net; 3 comments)<p>Though I like this one more, as it points to the source.
I'm struggling to see how the backporters thought this was an acceptable transformation. I don't know any of this code, and even the warning seems a little opaque to me initially. But it seems very obvious that you can't just reorder the lines.
Does anybody know what triggered the original fix in the first place? Just grep-ing?<p>If the kernel folks did what this company did . I.e have the compiler detect vulnerable code . The issue would have been avoided as well right ?
Is it just me or there an elephant in the room no one is talking about?<p>To me, so much blame lies with C's arcane rules, in this case for forcing you to declare variables earlier than you need them. If the compiler hadn't complained pointlessly and just let the programmer declare variables where they're needed, people wouldn't have had to try to "fix" it to begin with.<p>Apparently people would prefer to blame the kernel developers than the immaculate language that is C though...
So the only question remains, based on history of Chinese government (well, not only them but in this case the developer was a Chinese) wanting to weaken the security of software - was this intentional, and then the Chinese developer is a mole from them, or was a honest mistake?