On Thu, Jul 17, 2014 at 2:44 PM, Zach Brown <zab@xxxxxxxxx> wrote: > On Thu, Jul 17, 2014 at 04:43:40PM -0400, Theodore Ts'o wrote: > >> So in practice, the fact that we block at system init time shouldn't >> be a hardship for LibreSSL in most cases --- and in the case where you >> are running on an embedded system where there are barely any devices, >> no cycle counter, and nothing that produces enough interrupts to >> initialize the pool, what would you prefer that we do? Return data >> that might not be fully "seed grade entropy"? >> >> If you are determined to get data from a not a fully initialized >> entropy pool, then you can open /dev/urandom and get it via the old >> interface. > > That sounds reasonable. Maybe a slightly edited version of this writeup > could be dropped in the man page to give people context? And we'll be in a sad state in which we have a getrandom(2) syscall but there's no decent way to use srand without either opening /dev/urandom or mucking with AT_RANDOM. And the latter barely works because I think that most (all?) glibc versions clear it after using it to initialize their stack canaries. This isn't a regression, and it isn't a reason to object to getrandom(2), but if getrandom(2) goes in as is, I'll submit a patch adding the new flag immediately. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
