tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: /dev/random is hot garbage

Kamil Rytarowski <> writes:

> On 22.07.2019 13:12, Greg Troxel wrote:
>> Taylor R Campbell <> writes:
>>>> It would also be reasonable to have a sysctl to allow /dev/random to
>>>> return bytes anyway, like urandom would, and to turn this on for our xen
>>>> builders, as a different workaround.  That's easy, and it doesn't break
>>>> the way things are supposed to be for people that don't ask for it.
>>> What's the advantage of this over using replacing /dev/random by a
>>> symlink to /dev/urandom in the build system?
>>> A symlink can be restricted to a chroot, while a sysctl knob would
>>> affect the host outside the chroot.  The two would presumably require
>>> essentially the same privileges to enact.
>> None, now that I think of it.
>> So let's change that on the xen build host.
>> And, the other issue is that systems need randomness, and we need a way
>> to inject some into xen guests.  Enabling some with rndctl works, or at
>> least used to, even if it is theoretically dangerous.  But we aren't
>> trying to defend against the dom0.
> It looks like we need a paravirt random driver for xen that could solve
> the rust / random(6) problem.
> There is already viornd(4) for virtio(4).

rnd and Xen guests is a vexing problem.  Lots of things seem to consume
bits from the pool until you are often left with none.  For me it was
Kerberos authentication against a Postgresql DB, but ssh seems to use
them and it appears that some are consumed when you use ntpd keys with
peers.  I built this -> and feed
randomness into the Xen guests I have and other systems that I suspect
do not produce randomness on their own very well.  It is not at all a
perfect answer, but appears to work well enough for what I need.  For
Xen guests, a paravirt driver would seem to be a better answer.

Brad Spencer - - KC8VKS -

Home | Main Index | Thread Index | Old Index