lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 22 Jul 2014 11:49:52 +0200
From:	Hannes Frederic Sowa <>
To:	Theodore Ts'o <>
Cc:	George Spelvin <>,,
Subject: Re: [PATCH, RFC] random: introduce getrandom(2) system call


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 the syscall should block we make sure that we
> > extract the amount of bytes the user requested?
> On some systems, it's still possible that with a large /dev/random
> extraction, you could end up blocking for hours.  So either the
> getrandom(2) syscall needs to be uninterruptible, which has one set of
> problems (and not just the user typing ^C, but also things like being
> able to process alarms, which is highly problematic indeed), or you
> need to allow it to be interruptible by a signal, in which case
> userspace needs to check the error return for things like EINTR
> anyway.  And if you have to check the error return, you might as well
> check the number of bytes returned.

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 space, so it prevents this very common situation. Even if one would
like to extract 64 bytes randomness, one would often need two calls to
getrandom() on my virtualized systems. Would be great to know that in
blocking mode, either I get a -1 or the buffer is always filled and I
won't need to do pointer arithmetic to fill the rest of the buffer.

I still think it is a good idea even without caring about the signal

> Yes, one could in theory set up a new variant of "uninterruptible"
> signals that only exited if the signal caused the process to exit, and
> otherwise, forced a system call restart even if SA_INTERRUPTIBLE was
> not set in sigalarim, but that's add *way* more complexity than this
> deserves.

I don't want to do that. It is totally ok if we return -1 and set errno
to EINTR in case of pending signals.

> Basically, I view /dev/random as an advanced call, and someone who
> uses it should know what they are doing.  It's not the default for a
> reason.

I agree, but I still think this would make the interface a bit more
friendly to use.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists