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
For people who don't trust a hardware RNG which can not be audited,
the changes to add support for RDSEED can be troubling since 97% or
more of the entropy will be contributed from the in-CPU hardware RNG.
We now have a in-kernel khwrngd, so for those people who do want to
implicitly trust the
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
Unsigned variable total was tested for negativity after subtraction
operation. 2 instances.
Replaced that with the test of minuend being greater than subtrahend
before the subtraction.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80421
Reported-by: David Binderman dcb...@hotmail.com
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
On 07/17/2014 03:03 AM, Theodore Ts'o wrote:
For people who don't trust a hardware RNG which can not be audited,
the changes to add support for RDSEED can be troubling since 97% or
more of the entropy will be contributed from the in-CPU hardware RNG.
We now have a in-kernel khwrngd, so for
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
Dmitry Kasatkin d.kasat...@samsung.com wrote:
When ASYMMETRIC_KEYS=y, but depends on CRYPTO=m, selections will be also
modules.
In random config case OID_REGISTRY, MPILIB and ASN1 became modules producing
build
break. This patch removes asymmetric keys dependency from CRYPTO, but instead
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
Dmitry Kasatkin d.kasat...@samsung.com wrote:
When SIGNATURE=y but depends on CRYPTO=m, it selects MPILIB as module
producing build break. This patch makes digsig to select crypto for
correcting dependency.
I'll apply this one.
David
--
To unsubscribe from this list: send the line
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
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 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 05:38:20PM -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.
+SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
+ unsigned
On Thu, Jul 17, 2014 at 10:39:57AM -0700, H. Peter Anvin wrote:
I saw exactly one complaint to that nature, but that was from someone
who really wanted the nordrand option (at which point I observed that
it had inadvertently left RDSEED enabled which quickly got rectified.)
The implication
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
://git.infradead.org/users/pcmoore/selinux
into next (2014-07-17 03:05:51 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
tags/keys-next-20140717
for you to fetch changes up to e6df35b37ce9789a636d13f1e625d08ce029851b:
Merge
35 matches
Mail list logo
