Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout

[Michael Biebl]

Control: severity -1 wishlist
Control: retitle -1 allow crediting the seed file for some entropy
Control: forwarded -1  https://github.com/systemd/systemd/pull/10621

On Sat, 15 Dec 2018 09:17:46 +0100 Stefan Fritsch <sf at sfritsch.de> wrote:
> reassign 914297 systemd
> affects 914297 apache2
> thanks
> 
> On Saturday, 15 December 2018 02:24:54 CET Alexander E. Patrakov wrote:
> > Stefan Fritsch <sf at sfritsch.de>:
> > > The rng should be initialized after the seed is loaded from disk.
> > 
> > This is false according to systemd developers. Its state is changed,
> > but it is still not initialized, because they think that the seed
> > might come from a gold master image.
> 
> That's broken, then.

I don't agree with this assessment. systemd-random-seed works the way it
is supposed to work.

> It turns out there was a similar bug against openssh which was closed as 
> wontfix [1]. I don't see how apache can do anything about this, either.

There is. Don't request high-quality randomness during boot unless you
explicitly need it.

You best talk to the openssl maintainers and upstream about this.
It is my understanding that it's a behavioural change in openssl which
is causing all this by using getrandom() which in turn requires high
quality randomness on newer kernels.

> But I disagree with the systemd maintainers that there is nothing that systemd 
> can do about this. They should credit the entropy loaded from the seed but 
> save a new seed immediately after reading it during startup, to avoid that the 
> same seed is used more than once.

Even if systemd-random-seed get's an option to credit the entropy, this
will be opt in. So if you have to explicitly configure it, you have
better options like using virtio-rng. It's not even clear if the PR I
mentioned above is merged anytime soon and will make it into buster.

Second, it won't have any effect if no seed file exists. This can happen
on a first boot, so affects especially containers and VMs which
typically get rebuilt instead of rebooted after upgrades. And
incidentally those type of systems are affected the most.

Third, there are other init systems besides systemd, which behave the
same as systemd in that regard and are affected as well. So a -c switch
for systemd-random-seed, as proposed in the upstream PR, won't help
those systems either.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20181217/215d0e15/attachment.sig>