On Mon, Oct 14, 2013 at 01:16:41PM -0700, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > The patch below was submitted to be applied to the 3.11-stable tree. > > I fail to see how this patch meets the stable kernel rules as found at > Documentation/stable_kernel_rules.txt. This patch adds a new interface which allows architecture-specific code to address a security issue with the random driver for those platforms which define get_cycles() to return zero all the time. The most important p[latform for this is MIPS, since there are a lot of home routers which use MIPS, but the full list is: - MIPS - User mode Linux - Sparc 32 bit - M68K - M32R - Hexagon - H8/300 - FR-V - CRIS - AVR32 - ARC - METAG - Microblaze - SCORE - SH - Unicore32 On these platforms, when we try to sample entropy, the get_cycles() is a no-op, so the only thing that they can use is the jiffies counter, which is very coarse-grained and thus is highly unlikely to lead much in the way of unpredictability. The new interface allows architectures which don't have a CPU cycle counter, but might have something which is good enough for /dev/random, but not for the other users of get_cycles() to export that functionality via random_get_entropy(). An example of this is the MIPS platform, which where they have a DRAM refresh register which effectively is the low 5 bits of a CPU cycle counter register. They can't use this for get_cycles(), but it could be useful for random_get_entropy(). On other platforms, this commit will result in no change, so there is no risk to this patch. Cheers, - Ted -- 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