Kamil Rytarowski <n...@gmx.com> writes: > On 22.07.2019 13:12, Greg Troxel wrote: >> Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> 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 -> https://anduin.eldar.org/true-rng/ 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 - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org