Reviving an ancient thread: On 11/04/2014 02:18 AM, Daniel P. Berrange wrote:> On Mon, Nov 03, 2014 at 11:09:12AM -0500, Brian Rak wrote: >> I just ran into an issue where I had about 30 guests get duplicate mac >> addresses assigned. These were scattered across 30 different machines. >> >> Some debugging revealed that: >> >> 1) All the host machines were restarted within a couple seconds of each >> other >> 2) All the host machines had fairly similar libvirtd pids (within ~100 PIDs >> of each other) >> 3) Libvirt seeds the RNG using 'time(NULL) ^ getpid()' >> >> This perfectly explains why I saw so many duplicate mac addresses. >> >> Why is the RNG seed such a predictable value? Surely there has to be a >> better source of a random seed then the timestamp and the pid? >> >> The PID seems to me to be a very bad source of any randomness. I just ran a >> test across 60 of our hosts. 43 of them shared their PID with at least one >> other machine. > > We should probably seed it with data from /dev/urandom, and/or the new > Linux getrandom() syscall (or BSD equivalent).Did anyone ever open a BZ to track this? As far as I can tell, we still have a very predictable (meaning bad) seeding algorithm that permits large clusters to create collisions when their random number sequences sync up. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On 5/25/2018 8:58 AM, Eric Blake wrote:> Reviving an ancient thread: > > On 11/04/2014 02:18 AM, Daniel P. Berrange wrote: >> On Mon, Nov 03, 2014 at 11:09:12AM -0500, Brian Rak wrote: >>> I just ran into an issue where I had about 30 guests get duplicate mac >>> addresses assigned. These were scattered across 30 different machines. >>> >>> Some debugging revealed that: >>> >>> 1) All the host machines were restarted within a couple seconds of each >>> other >>> 2) All the host machines had fairly similar libvirtd pids (within >>> ~100 PIDs >>> of each other) >>> 3) Libvirt seeds the RNG using 'time(NULL) ^ getpid()' >>> >>> This perfectly explains why I saw so many duplicate mac addresses. >>> >>> Why is the RNG seed such a predictable value? Surely there has to be a >>> better source of a random seed then the timestamp and the pid? >>> >>> The PID seems to me to be a very bad source of any randomness. I >>> just ran a >>> test across 60 of our hosts. 43 of them shared their PID with at >>> least one >>> other machine. >> >> We should probably seed it with data from /dev/urandom, and/or the new >> Linux getrandom() syscall (or BSD equivalent). > > Did anyone ever open a BZ to track this? As far as I can tell, we > still have a very predictable (meaning bad) seeding algorithm that > permits large clusters to create collisions when their random number > sequences sync up. >I never did. We just switched to maintaining the mac ourselves, and not letting libvirt generate it.
Michal Privoznik
2018-May-25 14:17 UTC
Re: [libvirt-users] virRandomBits - not very random
On 05/25/2018 02:58 PM, Eric Blake wrote:> Reviving an ancient thread: > > On 11/04/2014 02:18 AM, Daniel P. Berrange wrote: >> On Mon, Nov 03, 2014 at 11:09:12AM -0500, Brian Rak wrote: >>> I just ran into an issue where I had about 30 guests get duplicate mac >>> addresses assigned. These were scattered across 30 different machines. >>> >>> Some debugging revealed that: >>> >>> 1) All the host machines were restarted within a couple seconds of each >>> other >>> 2) All the host machines had fairly similar libvirtd pids (within >>> ~100 PIDs >>> of each other) >>> 3) Libvirt seeds the RNG using 'time(NULL) ^ getpid()' >>> >>> This perfectly explains why I saw so many duplicate mac addresses. >>> >>> Why is the RNG seed such a predictable value? Surely there has to be a >>> better source of a random seed then the timestamp and the pid? >>> >>> The PID seems to me to be a very bad source of any randomness. I >>> just ran a >>> test across 60 of our hosts. 43 of them shared their PID with at >>> least one >>> other machine. >> >> We should probably seed it with data from /dev/urandom, and/or the new >> Linux getrandom() syscall (or BSD equivalent).I'm not quite sure that right after reboot there's going to be enough entropy. Every service that's starting wants some random bits. But it's probably better than what we have now. Michal
On 05/25/2018 09:17 AM, Michal Privoznik wrote:>>> We should probably seed it with data from /dev/urandom, and/or the new >>> Linux getrandom() syscall (or BSD equivalent). > > I'm not quite sure that right after reboot there's going to be enough > entropy. Every service that's starting wants some random bits. But it's > probably better than what we have now.Here's where we left things last time it came up: https://www.redhat.com/archives/libvir-list/2014-December/msg00573.html If gnutls has an interface that will give us random bits (gnutls_key_generate() in 3.0, perhaps), we should use THAT for all of our random bits (and forget about a seed), except when we are mocking things in our testsuite, and need a deterministic PRNG from a deterministic seed. If not (including if we are not linked with gnutls), then we should prefer the new Linux syscall but fall back to /dev/urandom for JUST enough bits for a seed; once we're seeded, stick with using our existing PRNG for all future bits (after all, we aren't trying to generate cryptographically secure keys using virRandomBits - and the places where we DO need crypto-strong randomness such as setting up TLS migration is where we are relying on gnutls to provide it rather than virRandomBits). So at this point, it's just a matter of someone writing the patches. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org