Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Jul 2014 23:05:34 +0200
From:      Mateusz Guzik <mjguzik@gmail.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        freebsd-security@freebsd.org, Steven Chamberlain <steven@pyro.eu.org>
Subject:   Re: Speed and security of /dev/urandom
Message-ID:  <20140719210534.GA4630@dft-labs.eu>
In-Reply-To: <20140719205350.GX93733@kib.kiev.ua>
References:  <53C85F42.1000704@pyro.eu.org> <20140719190348.GM45513@funkthat.com> <20140719192605.GV93733@kib.kiev.ua> <53CAD950.1010609@pyro.eu.org> <20140719205350.GX93733@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 19, 2014 at 11:53:50PM +0300, Konstantin Belousov wrote:
> On Sat, Jul 19, 2014 at 09:47:12PM +0100, Steven Chamberlain wrote:
> > On 19/07/14 20:26, Konstantin Belousov wrote:
> > > I think that using sysctl for non-management functionality is wrong.
> > > If this feature is for the libraries and applications, and not for
> > > system management and introspection utilities, it should be normal
> > > syscall.
> > 
> > If this is only to seed the arc4random in userland (with ~256 bytes or
> > so), it would be just like OpenBSD getentropy(2)?
> > 
> > Just yesterday, something very similar is proposed for Linux, called
> > getrandom(2):
> > http://lists.openwall.net/linux-kernel/2014/07/18/329
> 
> We, in fact, do not use sysctl for seeding SSP canary.  Kernel puts
> random bytes on stack, and libc fetches them.  But it is 64 bytes for
> 64-bit platforms, 32 bytes for 32-bit.
> 
> Yes, the interface of the getrandom(2) from the link above looks
> reasonable.  The big question is, indeed, about its supposed use
> models.  For one-time seeding of RNG with fixed amount of bytes,
> the ELF aux vector mechanism is much less intrusive and faster.

I believe the idea here is to have reliable source for reseeding after
fork.

-- 
Mateusz Guzik <mjguzik gmail.com>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140719210534.GA4630>