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 descr
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 CPU
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 r
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
Signed-off-by: Andrey
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 read
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 se
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 shou
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 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
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 Thu
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 f
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 reas
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 g
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 minh
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:
>
> i
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 DECLARE_COMPLETION(urandom_init
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) {
> +
Dmitry Kasatkin 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
> selects CRYPTO an
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 conven
Dmitry Kasatkin 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 "unsubscribe linux-crypto" in
> 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 s
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 atta
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 standar
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 /d
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.
> The
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 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 aro
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 descr
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
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,
> + unsig
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 implica
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
fede693f3fcc43d:
Merge branch 'stable-3.16' of git://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 c
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
Hi David,
On Thu, 17 Jul 2014 23:34:05 +0100 David Howells wrote:
>
> I have a number of sets of patches for you to pull. I've git-merged them
> together into a single branch (keys-next) as there are some conflicts and
> tagged the end.
>
> The component subsets are:
>
> (1) Tag keys-preparse
This is just an update to the commit description (and so I've only
included it_. A few more minor typos fixedup, and it includes Zach's
reviewed-by.
- Ted
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the
On 07/17/2014 03:08 PM, Theodore Ts'o wrote:
>
> There was another complaint more recently, that wasn't related to
> nordrand. And I was rather disturbed that in
> add_interrupt_randomness() 97% of the entropy was coming from RDSEED.
> I'm willing to have some of the entropy come from RDSEED by d
39 matches
Mail list logo
