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
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
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
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
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
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,
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
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
>
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)
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 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
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,
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
> 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 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
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
SYNOPSIS
#include
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 bytes which can be
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
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
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
On Sun, Jul 20, 2014 at 07:27:42PM +0200, Andreas Schwab wrote:
> Theodore Ts'o 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
Theodore Ts'o 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 44D5 214B
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
On Sun, Jul 20, 2014 at 08:50:06AM -0700, Andi Kleen wrote:
> Theodore Ts'o 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
> 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
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
Theodore Ts'o 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
--
To
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
Theodore Ts'o wrote:
> DESCRIPTION
>
> The system call getrandom() fills the buffer pointed to by buf
> with up to buflen random bytes which can be used to seed user
> space random number generators (i.e., DRBG's) or for other
> cryptographic processes. It should not be
Theodore Ts'o wrote:
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic processes. It should not be used
On Thu, 17 Jul 2014, 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.
If a call to get random data isn't allowed to either block or fail, what is it
supposed to return if there
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
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
On Thu, Jul 17, 2014 at 2:28 PM, Theodore Ts'o 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 been
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 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.
>
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 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
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
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
>
> 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
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) {
> +
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, 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:
>
>
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 wrote:
> And thanks btw.
>
> I don't suppose you guys know who we should talk to about possibly
> getting MAP_INHERIT_ZERO
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 wrote:
> we have diffs pending that will do the syscall method until we start
> to see it in libc :)
>
> So basically we're
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 wrote:
> On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote:
>> Hi Ted, yeah I understand the
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
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 wrote:
> On Thu, Jul 17, 2014 at 09:12:15AM -0700, Christoph Hellwig wrote:
>> On
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
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 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.
>
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
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
On 2014-07-17 at 11:18:15 +0200, Theodore Ts'o 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 probably
On Do, 2014-07-17 at 05:18 -0400, Theodore Ts'o wrote:
> SYNOPSIS
> #include
>
> 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 as a last
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
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
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
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
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
On Thu, 17 Jul 2014, 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.
If a call to get random data isn't allowed to either block or fail, what is it
supposed to return if there
100 matches
Mail list logo