Speed and security of /dev/urandom

John-Mark Gurney jmg at funkthat.com
Sat Jul 19 20:17:39 UTC 2014


Konstantin Belousov wrote this message on Sat, Jul 19, 2014 at 22:26 +0300:
> On Sat, Jul 19, 2014 at 12:03:48PM -0700, John-Mark Gurney wrote:
> > So, my suggestions:
> > 1)	Convert arc4random(9) in the kernel to use the random pool as
> > 	/dev/random uses.  I vaguely remeber there being an issue w/
> > 	arc4random(9) being used early in boot before /dev/random is
> > 	initalized which would complicate this change...
> > 2)	Convert arc4random(3) to use the sysctl, and if the sysctl fails,
> > 	kill the process.
> 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.

Though in the past we've been discouraged from adding new syscalls,
why, I don't know...

I'm fine w/ this, though we have had the sysctl for over 7 years..
so, using a sysctl will introduce anoying backward compatibility issues,
do you call back to the sysctl when the syscall isn't there? how do
you make the new code handle old OS's?

We can't remove arc4rand since old apps depend upon it...  apprently
the sysctl was added for SSP:
https://svnweb.freebsd.org/changeset/base/169727

> Being syscall, it also solves the issue of backward-compatibility,
> i.e. a new code, running on old kernel, get SIGSYS when using
> non-existing syscall.  If application is so sophisticated that
> it want to handle the situation, it can, by installing a signal
> handler.  Otherwise, it is terminated automatically.

Though broken applications (which there are many), could install SIGSYS
and ignore it still.. :)  broken apps are broken, not handling an error
is broken..  yes it's easier w/ SIGSYS, but not perfect...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."


More information about the freebsd-security mailing list