[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140717194812.GC24196@lenny.home.zabbo.net>
Date: Thu, 17 Jul 2014 12:48:12 -0700
From: Zach Brown <zab@...bo.net>
To: Theodore Ts'o <tytso@....edu>
Cc: linux-kernel@...r.kernel.org, linux-abi@...r.kernel.org,
linux-crypto@...r.kernel.org, beck@...nbsd.org
Subject: Re: [PATCH, RFC] random: introduce getrandom(2) system call
> SYNOPSIS
> #include <linux/random.h>
>
> int getrandom(void *buf, size_t buflen, unsigned int flags);
I certainly like the idea of getting entropy without having to worry
about fds.
> If the GRND_RANDOM flags bit is not set, then the /dev/raundom
(raundom typo)
> RETURN VALUE
> On success, the number of bytes that was returned is returned.
The description talks about filling the buffer, maybe say 'the number of
bytes filled is returned'?
> +DECLARE_COMPLETION(urandom_initialized);
static?
> +SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
> + unsigned int, flags)
> +{
> + int r;
> +
Michael Kerrisk wants you to return -EINVAL on unknown flags :)
http://lwn.net/Articles/588444/
> + if (count > 256)
> + return -EINVAL;
I'd vote for not having the limit. It seems easy enough to iterate over
the buffer. We'd need to clamp the count to ssize_t, though.
> + if (flags & GRND_RANDOM) {
> + return _random_read(!(flags & GRND_BLOCK), buf, count);
> + }
Do we want it to block by default and have the flag be _NONBLOCK? Feels
more.. familiar.
> + if (flags & GRND_BLOCK) {
> + r = wait_for_completion_interruptible(&urandom_initialized);
> + if (r)
> + return r;
I can *never* remember the rules for -ERESTARTSYS. The syscall callers
take care of this?
> + return urandom_read(NULL, buf, count, NULL);
I wonder if we want to refactor the entry points a bit more instead of
directly calling the device read functions. get_random_bytes() and
urandom_read() both have their own uninitialied use warning message and
tracing. Does the syscall want its own little extraction function as
well?
- z
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists