On Wed 2014-07-23 14:10:16, Hannes Frederic Sowa wrote:
On Wed, Jul 23, 2014, at 13:52, George Spelvin wrote:
I keep wishing for a more general solution. For example, some way to
have a spare extra fd that could be accessed with a special O_NOFAIL
flag.
That would allow any number
Hi,
I am wondering if we could improve the design of the system call a bit
to prevent programming errors.
Right now, EINVAL is returned in case of invalid flags (or in the older
version of getrandom() also if buflen is too large), EFAULT if buf is an
invalid address and EAGAIN if there is not
Hi,
On Wed, Jul 23, 2014, at 00:59, Theodore Ts'o wrote:
But why would you need to use GRND_RANDOM in your scenario, and accept
your application potentially getting stalled and stuck in amber for
perhaps hours? If you are going to accept your application stalling
like that, you can do the
I keep wishing for a more general solution. For example, some way to
have a spare extra fd that could be accessed with a special O_NOFAIL
flag.
That would allow any number of library functions to not fail, such as
logging from nasty corner cases.
But you'd have to provide one per thread, and
On Wed, Jul 23, 2014, at 13:52, George Spelvin wrote:
I keep wishing for a more general solution. For example, some way to
have a spare extra fd that could be accessed with a special O_NOFAIL
flag.
That would allow any number of library functions to not fail, such as
logging from nasty
Hello,
On Di, 2014-07-22 at 00:44 -0400, Theodore Ts'o wrote:
On Tue, Jul 22, 2014 at 03:02:20AM +0200, Hannes Frederic Sowa wrote:
Ted, would it make sense to specifiy a 512 byte upper bound limit for
random entropy extraction (I am not yet convinced to do that for
urandom) and in case
On Tue, Jul 22, 2014 at 11:49:52AM +0200, Hannes Frederic Sowa wrote:
I think a lot of checks are of the type if (getrandom() 0), so this
actually was the kind of programming errors I wanted to guard against.
Also, on some systems it is very likely that we return a short write to
user
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
SYNOPSIS
#include linux/random.h
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random
On Sun, Jul 20, 2014 at 05:25:40PM -0700, Dwayne Litzenberger wrote:
This could still return predictable bytes during early boot, though, right?
Read the suggetsed man page; especially, the version of the man page
in the commit description -v4 version of the patch.
getrandom(2) is a new
I don't like partial reads/writes and think that a lot of people get
them wrong, because they often only check for negative return values.
The v1 patch, which did it right IMHO, didn't do partial reads in the
case we're talking about:
+ if (count 256)
+ return -EINVAL;
On Mo, 2014-07-21 at 07:21 -0400, George Spelvin wrote:
I don't like partial reads/writes and think that a lot of people get
them wrong, because they often only check for negative return values.
The v1 patch, which did it right IMHO, didn't do partial reads in the
case we're talking about:
On Mo, 2014-07-21 at 17:27 +0200, Hannes Frederic Sowa wrote:
On Mo, 2014-07-21 at 07:21 -0400, George Spelvin wrote:
I don't like partial reads/writes and think that a lot of people get
them wrong, because they often only check for negative return values.
The v1 patch, which did it
On Tue, Jul 22, 2014 at 03:02:20AM +0200, Hannes Frederic Sowa wrote:
Ted, would it make sense to specifiy a 512 byte upper bound limit for
random entropy extraction (I am not yet convinced to do that for
urandom) and in case the syscall should block we make sure that we
extract the amount
Theodore Ts'o ty...@mit.edu writes:
#undef __NR_syscalls
-#define __NR_syscalls 277
+#define __NR_syscalls 278
You need to add the syscall to kernel/sys_ni.c too, otherwise it will be
impossible to build without random device.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
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
In the end people would just recall getentropy in a loop and fetch 256
bytes each time. I don't think the artificial limit does make any sense.
I agree that this allows a potential misuse of the interface, but
doesn't a warning in dmesg suffice?
It makes their code not work, so they can are
On Sun, Jul 20, 2014 at 08:50:06AM -0700, Andi Kleen wrote:
Theodore Ts'o ty...@mit.edu writes:
#undef __NR_syscalls
-#define __NR_syscalls 277
+#define __NR_syscalls 278
You need to add the syscall to kernel/sys_ni.c too, otherwise it will be
impossible to build without random
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
Theodore Ts'o ty...@mit.edu writes:
ERRORS
EINVAL The buflen value was invalid.
Also on unknown flags? Without that it would be impossible to probe for
implemented flags.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3
On Sun, Jul 20, 2014 at 07:27:42PM +0200, Andreas Schwab wrote:
Theodore Ts'o ty...@mit.edu writes:
ERRORS
EINVAL The buflen value was invalid.
Also on unknown flags? Without that it would be impossible to probe for
implemented flags.
We removed the cap on the buflen size
On So, 2014-07-20 at 13:03 -0400, George Spelvin wrote:
In the end people would just recall getentropy in a loop and fetch 256
bytes each time. I don't think the artificial limit does make any sense.
I agree that this allows a potential misuse of the interface, but
doesn't a warning in
On Thu, Jul 17, 2014 at 01:01:16PM -0400, Theodore Ts'o wrote:
The getrandom(2) system call is a superset of getentropy(2). When we
add the support for this into glibc, it won't be terribly difficult
nor annoying to drop the following in alongside the standard support
needed for any new system
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file
On Do, 2014-07-17 at 05:18 -0400, Theodore Ts'o wrote:
SYNOPSIS
#include linux/random.h
int getrandom(void *buf, size_t buflen, unsigned int flags);
Cool, I think the interface is sane.
Btw. couldn't libressl etc. fall back to binary_sysctl
kernel.random.uuid and seed with that
On 2014-07-17 at 11:18:15 +0200, Theodore Ts'o ty...@mit.edu wrote:
[...]
+/*
+ * Flags for getrandom(2)
+ *
+ * GAND_BLOCKAllow getrandom(2) to block
+ * GAND_RANDOM Use the /dev/random pool instead of /dev/urandom
+ */
Very minor nitpick: These should
On Thu, Jul 17, 2014 at 12:57:07PM +0200, Hannes Frederic Sowa wrote:
Btw. couldn't libressl etc. fall back to binary_sysctl
kernel.random.uuid and seed with that as a last resort? We have it
available for few more years.
Yes, they could. But trying to avoid more uses of binary_sysctl seems
On Thu, Jul 17, 2014 at 02:09:49PM +0200, Tobias Klauser wrote:
+/*
+ * Flags for getrandom(2)
+ *
+ * GAND_BLOCK Allow getrandom(2) to block
+ * GAND_RANDOM Use the /dev/random pool instead of /dev/urandom
+ */
Very minor nitpick: These should probably
On Do, 2014-07-17 at 08:52 -0400, Theodore Ts'o wrote:
On Thu, Jul 17, 2014 at 12:57:07PM +0200, Hannes Frederic Sowa wrote:
Btw. couldn't libressl etc. fall back to binary_sysctl
kernel.random.uuid and seed with that as a last resort? We have it
available for few more years.
Yes,
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
What's the reason to not implement exactly the same system call OpenBSD
does? Having
On Thu, Jul 17, 2014 at 09:12:15AM -0700, Christoph Hellwig wrote:
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
What's the
Hi Ted, yeah I understand the reasoning, it would be good if there was
a way to influence the various libc people to
ensure they manage to provide a getentropy().
On Thu, Jul 17, 2014 at 11:01 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Jul 17, 2014 at 09:12:15AM -0700, Christoph Hellwig
On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote:
Hi Ted, yeah I understand the reasoning, it would be good if there was
a way to influence the various libc people to
ensure they manage to provide a getentropy().
I don't anticipate that to be a problem. And before they do, and/or
if
we have diffs pending that will do the syscall method until we start
to see it in libc :)
So basically we're going to put that in right away :)
On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote:
Hi Ted, yeah I
And thanks btw.
I don't suppose you guys know who we should talk to about possibly
getting MAP_INHERIT_ZERO minherit() support?
On Thu, Jul 17, 2014 at 11:45 AM, Bob Beck b...@openbsd.org wrote:
we have diffs pending that will do the syscall method until we start
to see it in libc :)
So
Or perhaps to put that another way, since you don't do minherit -
maybe a FORK_ZERO for madvise? or a similar way
to do that?
On Thu, Jul 17, 2014 at 11:46 AM, Bob Beck b...@openbsd.org wrote:
And thanks btw.
I don't suppose you guys know who we should talk to about possibly
getting
On Thu, Jul 17, 2014, Theodore Ts'o wrote:
The getrandom(2) system call is a superset of getentropy(2). When we
add the support for this into glibc, it won't be terribly difficult
nor annoying to drop the following in alongside the standard support
needed for any new system call:
int
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
Minor nit:
@@ -469,6 +471,8 @@ static struct entropy_store nonblocking_pool = {
push_to_pool),
};
+DECLARE_COMPLETION(urandom_initialized);
+
static
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
+SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
+ unsigned int, flags)
+{
+ int r;
+
+ if (count 256)
+ return -EINVAL;
+
+ if (flags GRND_RANDOM) {
+ return
Hey Ted, one more nit. Yes, I have a bicycle too..
I see here we add a flag to make it block - whereas it seems most
other system calls that can block the flag is
added to make it not block (I.E. O_NONBLOCK, etc. etc.) Would it make
more sense to invert this so it was more
like the typical
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 07/17/2014 02:18 AM, Theodore Ts'o wrote:
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks,
On 07/17/2014 11:48 AM, Mark Kettenis wrote:
On Thu, Jul 17, 2014, Theodore Ts'o wrote:
The getrandom(2) system call is a superset of getentropy(2). When we
add the support for this into glibc, it won't be terribly difficult
nor annoying to drop the following in alongside the standard
On Thu, Jul 17, 2014 at 01:27:06PM -0700, Andy Lutomirski wrote:
+ return urandom_read(NULL, buf, count, NULL);
This can return -ERESTARTSYS. Does it need any logic to restart correctly?
Nope; because we only return -ERESTARTSYS when we haven't generated
any randomness yet. The way
On Thu, Jul 17, 2014 at 01:35:15PM -0700, Andy Lutomirski wrote:
Can we please have a mode in which getrandom(2) can neither block nor
fail? If that gets added, then this can replace things like AT_RANDOM.
AT_RANDOM has been around for a long time; it's not something we can
remove.
There
On Thu, Jul 17, 2014 at 12:48:12PM -0700, Zach Brown wrote:
+ 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
On Thu, Jul 17, 2014 at 2:28 PM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Jul 17, 2014 at 01:35:15PM -0700, Andy Lutomirski wrote:
Can we please have a mode in which getrandom(2) can neither block nor
fail? If that gets added, then this can replace things like AT_RANDOM.
AT_RANDOM has
On Thu, Jul 17, 2014 at 04:54:17PM -0400, Theodore Ts'o wrote:
On Thu, Jul 17, 2014 at 12:48:12PM -0700, Zach Brown wrote:
+ 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.
On Thu, Jul 17, 2014 at 11:45:56AM -0600, Bob Beck wrote:
we have diffs pending that will do the syscall method until we start
to see it in libc :)
One warning --- please don't check in the syscall number until it
actually hits mainline. Kees has another patch outstanding for
seccomp(2) that
48 matches
Mail list logo
