On 11/07/2012 11:10 PM, Kees Cook wrote: > On Wed, Nov 7, 2012 at 1:32 AM, Theodore Ts'o <ty...@mit.edu> wrote: >> On Tue, Nov 06, 2012 at 05:11:17PM -0800, Kees Cook wrote: >>> Hrm, I don't like this. get_random_int() specifically says: "Get a >>> random word for internal kernel use only." The intent of AT_RANDOM is >>> for userspace pRNG seeding (though glibc currently uses it directly >>> for stack protector and pointer mangling), which is not "internal >>> kernel use only". :) Though I suppose this is already being used for >>> the randomize_stack_top(), but I think it'd still be better to use >>> higher quality bits. >> >> Well, in practice, right now, get_random_int() is only being used for >> different cases of ASLR of one variety or another (either by the >> kernel in exec or mmap, or in userspace). So I'm not sure it really >> is a major issue. > > Hrm, yes. I see that the network code uses random32, not > get_random_int(). How are these different? Is one demonstrably better? I also have the same question in this point. Both generators are NOT considered safe for cryptographic use, but the comments of get_random_int() indicates that it could be used for several uses the cost of depleting entropy is too high, that's why I chose it. > >> If we also change get_random_int() to use a more secure cryptographic >> random generator (i.e., maybe AES instead of MD5), would that be >> sufficient to address your concerns? We're not using get_random_int() >> for anything that's timing sensitive, so that shouldn't be a problem. > > I wonder if using AES would have a measurable impact on fork speeds? > >> Or maybe we should just add an explicit CRNG set of routines (like the >> similar discussions to make an explicitly named PRNG set of routines), >> so callers can use whatever random number generator is appropriate for >> their performance and security needs. > > If we do use get_random_int() here, I'd at least like to see its > comment changed to reflect its actual purpose (since it's not > "internal use only") as well as its expected unpredictability. (This > would help document the utility of get_random_bytes() vs > get_random_int() vs random32().) > > -Kees Thanks, -Jeff
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
