Discussion:
[chrony-users] Chrony vs. Linux RNG
Denny Page
2018-05-07 17:11:36 UTC
Permalink
For what it’s worth, I got bit by this yesterday moving from 4.14.30 to 4.14.39. I had a couple servers hang for a few minutes in chrony startup. However, I also had several servers that were still hung in chrony startup after 30 minutes. Adding background fixes the issue as noted.

Denny
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Christian Ehrhardt
2018-05-16 06:46:56 UTC
Permalink
Post by Denny Page
For what it’s worth, I got bit by this yesterday moving from 4.14.30 to
4.14.39. I had a couple servers hang for a few minutes in chrony startup.
However, I also had several servers that were still hung in chrony startup
after 30 minutes. Adding background fixes the issue as noted.
I've seen it now too on one of my Fedora VMs running a server for
pool.ntp.org. The systemd service has a timeout of 90 seconds and
chronyd seems to be getting killed if it takes longer to start. Not
good.
As I understand it, this affects quite a few applications and there is
still some upstream discussion related to the RNG fix. Maybe it will
sort itself out on the kernel side.
You seem to track that already, do you have a few pointers to the Mailing
list archives that cover the ongoing discussion that you could share?
Post by Denny Page
If not, I think we should consider
releasing 3.3.1 with the fallback to /dev/urandom.
+1 on that suggestion
I Must admit I'm almost tempted to prefer implementing a fallback mechanism
in general (who knows what else than the mentioned kernel changes will
happen and make chrony hit that again).
Is there any argument against implementing the fallback mechanism no matter
what comes out on the kernel side of this discussion?
Post by Denny Page
--
Miroslav Lichvar
--
with "unsubscribe" in the subject.
with "help" in the subject.
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
Miroslav Lichvar
2018-05-16 08:50:24 UTC
Permalink
Post by Christian Ehrhardt
Post by Denny Page
As I understand it, this affects quite a few applications and there is
still some upstream discussion related to the RNG fix. Maybe it will
sort itself out on the kernel side.
You seem to track that already, do you have a few pointers to the Mailing
list archives that cover the ongoing discussion that you could share?
I don't have any pointers. I just saw it mentioned in one of the bugs
that were filed for Fedora when the kernel was updated.
https://bugzilla.redhat.com/show_bug.cgi?id=1572944
Post by Christian Ehrhardt
I Must admit I'm almost tempted to prefer implementing a fallback mechanism
in general (who knows what else than the mentioned kernel changes will
happen and make chrony hit that again).
Is there any argument against implementing the fallback mechanism no matter
what comes out on the kernel side of this discussion?
One is that chronyd's start would not be deterministic. If
/dev/urandom it's not available (e.g. in a chroot), or the access is
blocked by SELinux, AppArmor, etc, chronyd would sometimes fail to
start.

The other is that falling back to a more predictable PRNG will make it
a bit easier to spoof a server reply (i.e. guess the transmit
timestamp and the UDP port number). However, we still use /dev/urandom
when getrandom() is not available, so the worst supported case will
not change.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Loading...