On Sat, 13 Jul 2013, Theodore Ts'o wrote: > > The problem we have actually encountered was 902c098a ... it's not obvious > > how that patch would be fixing any security related issue (strictly > > speaking, it could actually create a new security problem). > > It's not even closely tight to the rest of the patches in the series > > (supposedly some of those patches is fixing some particular CVE ...). > > > > So I still fail to see a proper explanation why 902c098a itself is > > included in the stable tree. > > The specific reason for these changes was the following research work: > > https://factorable.net/ > > In order to deal with this, we needed to sample randomness > unconditionally for every single interrupt. Historically, kernel > developers had been very hesitant to sample for randomness because of > the potential performance hit. As a result, most of the drivers > didn't sample for randomness, with the result shown above. The fix > was to sample for randomness unconditionally; commit 902c098a was to > eliminate the performance impact of always sampling for randomness. Hi Ted, thanks for explanation. This unfortunately brings more questions / remarks, namely: - this doesn't seem to be explained *anywhere* in the changelog (please correct me if I am wrong), and therefore completely invisible to consumers of -stable branch, who are just going to be "ok, nice /dev/random rework, but what the heck is it doing in -stable"? This actually connects to the complaints of some folks from our beloved "security community" (spender, for example). I agree that their arguments are very often overboard, as it's not really easily possible to evaluate whether each and every patch has security implications. But here, the situation seems to be different -- it was known from the very beginning that this all is security related, all the rework has been done with this in mind, but I fail to see proper background in changelog. - was the rush really necessary? If I got the dates right, 3.6 (containing big part of this) was released Sep 30th, first stable to contain this was 3.0.41, released Aug 15th. With such a huge rework, it was likely that there will be bug (and there indeed was). If the patches were kept in mainline for a little longer, the bug will probably be fixed there, and only then folded properly into -stable. But as it has been done this way, the bug was first discovered in -stable and only then fixed in Linus' tree. To me, this clearly sounds like failure of -stable process. The buggy keys are spread all over the Internet already anyway, so fixing this "now" or a 3 weeks later after much more testing is performed doesn't really provide any additional security benefit anyway. Please, don't get me wrong. I am not targetting this very patchset specifically. I am just trying to point out why sometimes our life with -stable is difficult, and I think it doesn't necessarily have to be. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html