On Sun, Jul 20, 2014 at 12:26:22PM -0400, George Spelvin wrote: > One basic question... why limit this to /dev/random? > > If we're trying to avoid fd exhaustion attacks, wouldn't an "atomically > read a file into a buffer" system call (that could be used on > /dev/urandom, or /etc/hostname, or /proc/foo, or...) be more useful? > > E.g. > > ssize_t readat(int dirfd, char const *path, struct stat *st, > char *buf, size_t len, int flags); > > It's basically equivalent to openat(), optional fstat() (if st is non-NULL), > read(), close(), but it doesn't allocate an fd number. > > Is it necessary to have a system call just for entropy? > > If you want a "urandom that blocks until seeded", you can always create > another device node for the purpose. I'd really rather not go down this path. Your readat(2) proposal is interesting, but it adds a whole lot of complications. For example, just simply booting a new kernel doesn't guarantee that a new device node for "blocks until seeded" will exist. So that means a lot of applications will just either continue to use /dev/urandom, or have to put in fallback code to first try the new device name, and then fall back to /dev/urandom. (And of course, they have to deal with what to do if /dev/urandom doesn't exist --- which presumably would be raise(SIGKILL), but we're now talking about a number of lines of codes that application writers would have to get right.) Readat(2) would also have to get linked into auditing, and LSM, and honestly, it's a lot more work that I'm not all that interested in doing and trying to get right. > If you do stick with a random-specific call, specifying the entropy > in bits (with some specified convention for the last fractional byte) > is anothet interesting idea. Perhaps too prone to bugs, though. > (People thinking it's bytes and producing low-entropy keys.) Definitely not worth the complexity. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
