Discussion:
[libvirt-users] virRandomBits - not very random
Brian Rak
2014-11-03 16:09:12 UTC
Permalink
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.
Daniel P. Berrange
2014-11-04 08:18:28 UTC
Permalink
Post by Brian Rak
I just ran into an issue where I had about 30 guests get duplicate mac
addresses assigned. These were scattered across 30 different machines.
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).

Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Eric Blake
2018-05-25 12:58:14 UTC
Permalink
Post by Daniel P. Berrange
Post by Brian Rak
I just ran into an issue where I had about 30 guests get duplicate mac
addresses assigned. These were scattered across 30 different machines.
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
Brian Rak
2018-05-25 13:27:34 UTC
Permalink
Post by Daniel P. Berrange
Post by Brian Rak
I just ran into an issue where I had about 30 guests get duplicate mac
addresses assigned.  These were scattered across 30 different machines.
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-05-25 14:17:41 UTC
Permalink
Post by Daniel P. Berrange
Post by Brian Rak
I just ran into an issue where I had about 30 guests get duplicate mac
addresses assigned.  These were scattered across 30 different machines.
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
Eric Blake
2018-05-25 14:37:44 UTC
Permalink
Post by Michal Privoznik
Post by Daniel P. Berrange
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
Martin Kletzander
2018-05-29 13:38:38 UTC
Permalink
Post by Eric Blake
Post by Michal Privoznik
Post by Daniel P. Berrange
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.
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.
Actually, do we need to have a fallback at all? Can't we just drop all the
gross parts of the code the conditionally compile based on GNUTLS support? Why
don't we have gnutls required?
Post by Eric Blake
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
--
libvir-list mailing list
https://www.redhat.com/mailman/listinfo/libvir-list
Michal Privoznik
2018-05-29 13:44:42 UTC
Permalink
Post by Eric Blake
Post by Michal Privoznik
Post by Daniel P. Berrange
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.
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.
Actually, do we need to have a fallback at all?  Can't we just drop all the
gross parts of the code the conditionally compile based on GNUTLS
support?  Why
don't we have gnutls required?
That's exactly what I'm suggesting in my patches [1]. gnutls is widely
available (including Linux, Windows, *BSD, Mac Os X). However, before
doing that we need to fix virRandomBits() to actually call gnutls_rnd().

1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html

Michal
John Ferlan
2018-05-29 14:06:25 UTC
Permalink
Post by Michal Privoznik
Post by Eric Blake
Post by Michal Privoznik
Post by Daniel P. Berrange
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.
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.
Actually, do we need to have a fallback at all?  Can't we just drop all the
gross parts of the code the conditionally compile based on GNUTLS
support?  Why
don't we have gnutls required?
That's exactly what I'm suggesting in my patches [1]. gnutls is widely
available (including Linux, Windows, *BSD, Mac Os X). However, before
doing that we need to fix virRandomBits() to actually call gnutls_rnd().
1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html
I have this faint recollection of one of the CI platform builds failing
because something in the gnutls* family didn't exist there when I was
making the changes to add the domain master secret code.... After a bit
of digging, it seems it was a perhaps a CENTOS6 environment:

https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html

and since IIUC that's not an issue any more....

John

now if I could only figure out why my mail client seems to be dropping
any patches with "crypto" in the subject line (I'm missing patches 2-4
and 10 from the series referenced above)...
Martin Kletzander
2018-05-30 20:21:54 UTC
Permalink
Post by John Ferlan
Post by Michal Privoznik
Post by Eric Blake
Post by Michal Privoznik
Post by Daniel P. Berrange
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.
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.
Actually, do we need to have a fallback at all?  Can't we just drop all the
gross parts of the code the conditionally compile based on GNUTLS
support?  Why
don't we have gnutls required?
That's exactly what I'm suggesting in my patches [1]. gnutls is widely
available (including Linux, Windows, *BSD, Mac Os X). However, before
doing that we need to fix virRandomBits() to actually call gnutls_rnd().
1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html
I have this faint recollection of one of the CI platform builds failing
because something in the gnutls* family didn't exist there when I was
making the changes to add the domain master secret code.... After a bit
https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html
and since IIUC that's not an issue any more....
Oh, cool to know. Michal also found the patch [1] where Dan switched the gnutls
from being mandatory to making it optional and there is no explanation for that
change in the commit message:

[1] f587c27768ee13f5bed6a9262106307b7a124403
Post by John Ferlan
John
now if I could only figure out why my mail client seems to be dropping
any patches with "crypto" in the subject line (I'm missing patches 2-4
and 10 from the series referenced above)...
Maybe you have some weird server-side filter for it?
Daniel P. Berrangé
2018-06-01 10:17:44 UTC
Permalink
Post by Martin Kletzander
Post by John Ferlan
Post by Michal Privoznik
Post by Eric Blake
Post by Michal Privoznik
Post by Daniel P. Berrange
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.
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.
Actually, do we need to have a fallback at all?  Can't we just drop all the
gross parts of the code the conditionally compile based on GNUTLS
support?  Why
don't we have gnutls required?
That's exactly what I'm suggesting in my patches [1]. gnutls is widely
available (including Linux, Windows, *BSD, Mac Os X). However, before
doing that we need to fix virRandomBits() to actually call gnutls_rnd().
1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html
I have this faint recollection of one of the CI platform builds failing
because something in the gnutls* family didn't exist there when I was
making the changes to add the domain master secret code.... After a bit
https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html
and since IIUC that's not an issue any more....
Oh, cool to know. Michal also found the patch [1] where Dan switched the gnutls
from being mandatory to making it optional and there is no explanation for that
[1] f587c27768ee13f5bed6a9262106307b7a124403
Not all usage scenarios in libvirt have required GNUTLS - only the remote
driver, when using stateful virt drivers. If you're just biulding libvirt
for usage with ESX/HyperV/etc, there's no reason you'd want GNUTLS historically.

Also note when building the setuid libvirt pieces we must never use GNUTLS
because its library constructors do very bad things leading to CVEs.


Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Martin Kletzander
2018-06-01 12:01:03 UTC
Permalink
Post by Daniel P. Berrangé
Post by Martin Kletzander
Post by John Ferlan
Post by Michal Privoznik
Post by Eric Blake
Post by Michal Privoznik
Post by Daniel P. Berrange
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.
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.
Actually, do we need to have a fallback at all?  Can't we just drop all the
gross parts of the code the conditionally compile based on GNUTLS
support?  Why
don't we have gnutls required?
That's exactly what I'm suggesting in my patches [1]. gnutls is widely
available (including Linux, Windows, *BSD, Mac Os X). However, before
doing that we need to fix virRandomBits() to actually call gnutls_rnd().
1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html
I have this faint recollection of one of the CI platform builds failing
because something in the gnutls* family didn't exist there when I was
making the changes to add the domain master secret code.... After a bit
https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html
and since IIUC that's not an issue any more....
Oh, cool to know. Michal also found the patch [1] where Dan switched the gnutls
from being mandatory to making it optional and there is no explanation for that
[1] f587c27768ee13f5bed6a9262106307b7a124403
Not all usage scenarios in libvirt have required GNUTLS - only the remote
driver, when using stateful virt drivers. If you're just biulding libvirt
for usage with ESX/HyperV/etc, there's no reason you'd want GNUTLS historically.
Also note when building the setuid libvirt pieces we must never use GNUTLS
because its library constructors do very bad things leading to CVEs.
Good to know, thanks for the info. I'll need to read up on the gnutls
constructors (is it just gnutls or some other libs as well?) even though I
remember researching something related to it some time ago. However that
doesn't mean it has to be optional.

Do you think there are people who would be bothered by the requirement of
gnutls? I'm sure most of them have gnutls anyway. Some of them even need to
have, for example if you have a look at virCryptoHashBuf() its stub returns -1
and it is used in ESX. If you compile without GNUTLS, all the functions that
require it will just fail and it's not something that is used rarely.

We can we make it required only if you are building with qemu or remote or esx
or basically something that requires it. Encryption of RAW volumes for example.
Or lock driver. But I don't think there are some who run the builds themselves
and doesn't want gnutls on their system. I can't think of a reason for having
it and not linking libvirt with it.
Post by Daniel P. Berrangé
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
https://www.redhat.com/mailman/listinfo/libvir-list
Daniel P. Berrangé
2018-06-01 12:25:26 UTC
Permalink
Post by Martin Kletzander
Post by Daniel P. Berrangé
Post by Martin Kletzander
Post by John Ferlan
Post by Michal Privoznik
Post by Eric Blake
Post by Michal Privoznik
Post by Daniel P. Berrange
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.
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.
Actually, do we need to have a fallback at all?  Can't we just drop all the
gross parts of the code the conditionally compile based on GNUTLS
support?  Why
don't we have gnutls required?
That's exactly what I'm suggesting in my patches [1]. gnutls is widely
available (including Linux, Windows, *BSD, Mac Os X). However, before
doing that we need to fix virRandomBits() to actually call gnutls_rnd().
1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html
I have this faint recollection of one of the CI platform builds failing
because something in the gnutls* family didn't exist there when I was
making the changes to add the domain master secret code.... After a bit
https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html
and since IIUC that's not an issue any more....
Oh, cool to know. Michal also found the patch [1] where Dan switched the gnutls
from being mandatory to making it optional and there is no explanation for that
[1] f587c27768ee13f5bed6a9262106307b7a124403
Not all usage scenarios in libvirt have required GNUTLS - only the remote
driver, when using stateful virt drivers. If you're just biulding libvirt
for usage with ESX/HyperV/etc, there's no reason you'd want GNUTLS historically.
Also note when building the setuid libvirt pieces we must never use GNUTLS
because its library constructors do very bad things leading to CVEs.
Good to know, thanks for the info. I'll need to read up on the gnutls
constructors (is it just gnutls or some other libs as well?) even though I
remember researching something related to it some time ago. However that
doesn't mean it has to be optional.
Do you think there are people who would be bothered by the requirement of
gnutls? I'm sure most of them have gnutls anyway. Some of them even need to
have, for example if you have a look at virCryptoHashBuf() its stub returns -1
and it is used in ESX. If you compile without GNUTLS, all the functions that
require it will just fail and it's not something that is used rarely.
We can we make it required only if you are building with qemu or remote or esx
or basically something that requires it. Encryption of RAW volumes for example.
Or lock driver. But I don't think there are some who run the builds themselves
and doesn't want gnutls on their system. I can't think of a reason for having
it and not linking libvirt with it.
I should clarify - I've no objection to making GNUTLS mandatory at configure
time - just that we need to continue to have WITH_GNUTLS conditionals in some
parts of the code in order to support the setuid build without GNUTLS. So we
might be able to remove some of the WITH_GNUTLS bits, but not all of them.

Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Martin Kletzander
2018-06-01 13:03:19 UTC
Permalink
Post by Daniel P. Berrangé
Post by Martin Kletzander
Post by Daniel P. Berrangé
Post by Martin Kletzander
Post by John Ferlan
Post by Michal Privoznik
Post by Eric Blake
Post by Michal Privoznik
Post by Daniel P. Berrange
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.
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.
Actually, do we need to have a fallback at all?  Can't we just drop all the
gross parts of the code the conditionally compile based on GNUTLS
support?  Why
don't we have gnutls required?
That's exactly what I'm suggesting in my patches [1]. gnutls is widely
available (including Linux, Windows, *BSD, Mac Os X). However, before
doing that we need to fix virRandomBits() to actually call gnutls_rnd().
1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html
I have this faint recollection of one of the CI platform builds failing
because something in the gnutls* family didn't exist there when I was
making the changes to add the domain master secret code.... After a bit
https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html
and since IIUC that's not an issue any more....
Oh, cool to know. Michal also found the patch [1] where Dan switched the gnutls
from being mandatory to making it optional and there is no explanation for that
[1] f587c27768ee13f5bed6a9262106307b7a124403
Not all usage scenarios in libvirt have required GNUTLS - only the remote
driver, when using stateful virt drivers. If you're just biulding libvirt
for usage with ESX/HyperV/etc, there's no reason you'd want GNUTLS historically.
Also note when building the setuid libvirt pieces we must never use GNUTLS
because its library constructors do very bad things leading to CVEs.
Good to know, thanks for the info. I'll need to read up on the gnutls
constructors (is it just gnutls or some other libs as well?) even though I
remember researching something related to it some time ago. However that
doesn't mean it has to be optional.
Do you think there are people who would be bothered by the requirement of
gnutls? I'm sure most of them have gnutls anyway. Some of them even need to
have, for example if you have a look at virCryptoHashBuf() its stub returns -1
and it is used in ESX. If you compile without GNUTLS, all the functions that
require it will just fail and it's not something that is used rarely.
We can we make it required only if you are building with qemu or remote or esx
or basically something that requires it. Encryption of RAW volumes for example.
Or lock driver. But I don't think there are some who run the builds themselves
and doesn't want gnutls on their system. I can't think of a reason for having
it and not linking libvirt with it.
I should clarify - I've no objection to making GNUTLS mandatory at configure
time - just that we need to continue to have WITH_GNUTLS conditionals in some
parts of the code in order to support the setuid build without GNUTLS. So we
might be able to remove some of the WITH_GNUTLS bits, but not all of them.
Oh, OK. Great.
Post by Daniel P. Berrangé
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Loading...