On 22.07.2019 13:12, Greg Troxel wrote: > Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> 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).
Attachment:
signature.asc
Description: OpenPGP digital signature