service urandom-seed takes too long on boot

  • Open
  • quality assurance status badge
Details
7 participants
  • Alex Sassmannshausen
  • Brice Waegeneire
  • Leo Famulari
  • Ludovic Courtès
  • raid5atemyhomework
  • Robert Vollmert
  • Stefan
Owner
unassigned
Submitted by
Robert Vollmert
Severity
important

Debbugs page

R
R
Robert Vollmert wrote on 25 Jun 2019 11:12
(address . bug-guix@gnu.org)
F88CEF04-9BFA-4886-8A2D-AD84AE278D07@vllmrt.net
On my VPS, booting takes forever (long enough that for a long
time I thought the install had failed). I just rebooted again,
and it took over 7 minutes, see attached screenshot.

I would suggest skipping the seeding from /dev/hwrng by default
if /var/lib/random-seed is available. I’m assuming here that my
problem is not too rare — if it is, an option to disable the
seeding from /dev/hwrng seems like a good idea.
Attachment: file
A
A
Alex Sassmannshausen wrote on 26 Jun 2019 02:41
(address . bug-guix@gnu.org)(address . 36380@debbugs.gnu.org)
871rzg3cpw.fsf@gmail.com
Hi Robert,

Robert Vollmert <rob@vllmrt.net> writes:

Toggle quote (9 lines)
> On my VPS, booting takes forever (long enough that for a long
> time I thought the install had failed). I just rebooted again,
> and it took over 7 minutes, see attached screenshot.
>
> I would suggest skipping the seeding from /dev/hwrng by default
> if /var/lib/random-seed is available. I’m assuming here that my
> problem is not too rare — if it is, an option to disable the
> seeding from /dev/hwrng seems like a good idea.

I'm not sure I'm qualified on best practices with regard to urandom, but
anecdotally, my servers are booting pretty fast, within a minute,
consistently. This is even when booting a qemu virtual image rather
than a VPS.

Perhaps something else is going on here?

Alex
L
L
Leo Famulari wrote on 26 Jun 2019 08:47
(name . Robert Vollmert)(address . rob@vllmrt.net)(address . 36380@debbugs.gnu.org)
20190626154721.GA2999@jasmine.lan
On Tue, Jun 25, 2019 at 08:12:28PM +0200, Robert Vollmert wrote:
Toggle quote (4 lines)
> On my VPS, booting takes forever (long enough that for a long
> time I thought the install had failed). I just rebooted again,
> and it took over 7 minutes, see attached screenshot.

Yikes, that's way too long. Can you say what VPS it is?

Toggle quote (5 lines)
> I would suggest skipping the seeding from /dev/hwrng by default
> if /var/lib/random-seed is available. I’m assuming here that my
> problem is not too rare — if it is, an option to disable the
> seeding from /dev/hwrng seems like a good idea.

Originally I added the HWRNG read specifically the for VM / VPS use case
[0], where the first boot environment is relatively deterministic. I
agree it's superfluous if the random-seed file is handled properly but
it's nice to unconditionally have this other entropy source that avoids
the pitfalls of file-based entropy seeding.

Ideally the hypervisor would seed the guest's HWRNG interface with the
host's /dev/urandom, which would avoid significant delays. It seems they
are using some other more limited resource instead.

Does anyone else have an opinion or experience with this issue? It would
be great to know how widespread it is.

[0]
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAl0Tk4QACgkQJkb6MLrK
fwhzQQ/8Dec8zVia6JlNfy5x142pZNTseg3wV2ngdEeJrpViVjhtXRvfMY/UYOPF
9mct+VviPHSae8oSJG5S+rPA7xQwXedMdMRsDjdORajEoB7WUZ7FKYWmkRvuhatB
bJPisHnYkZXE/+Un4hQEYQV8Ntpbr1hmBmC2DTzqpLbL13nD1lxfjolRg67Shywt
TkQOMt81waqRQdyY2tNK6whjgFMfzAyTdsW/kaMzGWgtyI8ze4vus1F4wG1LWVgH
47O7q8uRq+y94jKfTN3RzRLhdK7jRtClAZi5nLETwbh+mCO82fiq+/5jCMKHo63E
JGpL7LoIDwZCLKC9K+VVpHfUIUpw8nV42eY/2VW6NyF5n/dFszAsbnwNa4vJVpD/
w6YAr83y1LwiThz0cq5e/kgW8PWuDTCzUtJCXJ+9fMqZjhxkLbY21yZHyLwu1yKl
AP0GY3+77AcDbqvXXF7br19l5B2KNF2TjV5uhssEnnTSy80RWufQQ8N3HeoGbHKF
C68Ls/XQ42Zyfy5r+lulPOF0C/2d+pNJJ7aFVqFTw8wpWApwhexafDqdmBoNyNH3
31J+gzdNZ+SukUoE0x+NkBkgIgedLU/D4tYh7kgPJKGFfZpomLGsry83sgy1wMlE
/JvJqQQsgPRp6YD6P+37Vil5ob6KzlV1QmUhH4H4XI/WiUjJnlI=
=JjKb
-----END PGP SIGNATURE-----


R
R
Robert Vollmert wrote on 26 Jun 2019 09:02
(name . Leo Famulari)(address . leo@famulari.name)(address . 36380@debbugs.gnu.org)
51B21C84-982D-4DC0-AEA7-A32EA0F855B8@vllmrt.net
Toggle quote (9 lines)
> On 26. Jun 2019, at 17:47, Leo Famulari <leo@famulari.name> wrote:
>
> On Tue, Jun 25, 2019 at 08:12:28PM +0200, Robert Vollmert wrote:
>> On my VPS, booting takes forever (long enough that for a long
>> time I thought the install had failed). I just rebooted again,
>> and it took over 7 minutes, see attached screenshot.
>
> Yikes, that's way too long. Can you say what VPS it is?

It’s with arpnetworks.com, their default “small" VPS. I don’t
really know more; here’s some dmesg output that might be relevant,
happy to provide more info.

[ 0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1.1 04/01/2014
[ 0.000000] Hypervisor detected: KVM
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[ 0.000000] kvm-clock: cpu 0, msr 2a782001, primary cpu clock
[ 0.000000] kvm-clock: using sched offset of 1160634602574609 cycles
[ 0.000002] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.000004] tsc: Detected 3066.774 MHz processor
L
L
Ludovic Courtès wrote on 27 Jun 2019 08:20
(name . Leo Famulari)(address . leo@famulari.name)
87zhm3xdfu.fsf@gnu.org
Hi Leo,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (7 lines)
> On Tue, Jun 25, 2019 at 08:12:28PM +0200, Robert Vollmert wrote:
>> On my VPS, booting takes forever (long enough that for a long
>> time I thought the install had failed). I just rebooted again,
>> and it took over 7 minutes, see attached screenshot.
>
> Yikes, that's way too long. Can you say what VPS it is?

We had a “bug report” at
due to the same issue:

The first time I loaded Guix the boot process took an unusually long
time. At one point the system appeared to lock up for about five
minutes before continuing. In the end, from boot menu to graphical
login screen, the start-up time totalled about ten minutes.

The author says they were running Guix in VirtualBox. I’m glad Robert’s
bug report has more info than that one. :-)

What should we do?

Ludo’.
L
L
Ludovic Courtès wrote on 27 Jun 2019 08:20
control message for bug #36380
(address . control@debbugs.gnu.org)
87y31nxdfe.fsf@gnu.org
severity 36380 important
quit
L
L
Leo Famulari wrote on 27 Jun 2019 12:03
Re: bug#36380: service urandom-seed takes too long on boot
(name . Ludovic Courtès)(address . ludo@gnu.org)
20190627190314.GA7403@jasmine.lan
On Thu, Jun 27, 2019 at 05:20:21PM +0200, Ludovic Courtès wrote:
Toggle quote (9 lines)
> We had a “bug report” at
> <https://distrowatch.com/weekly.php?issue=20190624#guixsd>, which may be
> due to the same issue:
>
> The first time I loaded Guix the boot process took an unusually long
> time. At one point the system appeared to lock up for about five
> minutes before continuing. In the end, from boot menu to graphical
> login screen, the start-up time totalled about ten minutes.

Perhaps, but if the reason for the slowness on their first boot was a
suboptimal /dev/hwrng source, I would expect it to be equally slow for
each boot, since we unconditionally read 64 bytes each time.

However, their next sentence says, "Curiously, after the first boot,
Guix started up considerably faster, generally taking less than a minute
to arrive at the login screen."

They are using an old machine with a spinning disk, so who knows...
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAl0VEvAACgkQJkb6MLrK
fwi72Q/+KFZ5pVsyeDr/ouu9JIGSCfc+cCpSu88cOW0MhtWqLN+J38Gt+mtHHPIq
n847ae2WKe+Sa/snMFmqRAkUgUw4vcjJgYFPwPU2f+EQP6Hl422mgdKknbMJbsaN
poOQJyf/I5sY96BPYHICegFfHUVd8NHwDTFbcPnh6TfU9WN/fx4CMuG6fy5Ten3/
NSZ6m7QFYncrwvb9J9JJmNFl3LFhulA4Y68/lFnGBL3xVSHNDndOMBUMssg6EmsI
y+oLIYiUsfdjfW/OsvZQNqdbGszgk0Ifany8n+u4KOTlMjv7mhIlXPyL0TfkU3XW
5Vc5R7ga7f4jxRo2cDAIP55HhZ+lc3Y5nr59mnxzw/bIPWZpdtqYqE0zOlq4EIQ5
eQFvSZdQv4yLXp5pD8hSxuLlh3Gj3qjqIqgFqf54d3XL+bWd+X1M6F1u+pKKLaQa
js/O3yoR1xr11TH9fK2psA3FWwZWVal7mc/ujDHtd+njvf56jrbBZ10wqZlAkhPf
2mbecVMNw9udQCrY+crivuiF+oCjYjNBQ85l7mUed92xK1eLcraPYJLpN/8ZEsdJ
HvBqSQOBkhQvstvC1GaSAo5xAZj+mX0UblRrM5CqVyZEDgBvqnX3cuayjRWUUthE
moHJvT0CpCvQHDhYI/gSNFJhLPBOY11fZtoV5oS3XYKrmcgz0/Q=
=iTHL
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 27 Jun 2019 12:19
(name . Robert Vollmert)(address . rob@vllmrt.net)(address . 36380@debbugs.gnu.org)
20190627191915.GA9591@jasmine.lan
On Wed, Jun 26, 2019 at 06:02:03PM +0200, Robert Vollmert wrote:
Toggle quote (4 lines)
> It’s with arpnetworks.com, their default “small" VPS. I don’t
> really know more; here’s some dmesg output that might be relevant,
> happy to provide more info.

Okay, I've asked them about it on IRC:


Let's wait and see what they think about the issue.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAl0VFrIACgkQJkb6MLrK
fwjsXBAA71rlRFfbPpKY+ReKmJXfl9BygIKBSdiyI3Bm02DDUNQthEmXixJlZ/Bm
mBPaU7tnj83qlmCuF1z08oDj0hXgrvNTX9V4+BGK7IXLGPiG1ij3+/c6n+gW1ywG
BhanbNXiarEZ3gQ1fN0f25qOqmqRQnJM+qx+RgelIJUsJ1TNHxE056fi1AiayqBc
G70FgAVIn5ChrgiooK36S7FbM4d0KbHjcQSH7v594/iVXPyc5oOZKuIyWDuybBTt
Y8SdVT6Y151CwNXVia8+Y0g+esl3Pl20JF/V1CJUI7ZSLtTx0hvnDOuIa86xYkU5
ELfZ6D4h+BhaOKnUCTkvfc2RaEsAL9+oVLvteAraW62lN3+7Mq7vtXvlNvBXsuXt
b9FHQA96m8zwChJPb0lZIsQ1NBPqF7ToahfZLl9XzlKgyaD8Slca5+v3MnqelefA
r/+1rizG3a0KJIuZ95P3NSemPe/R3CNuiCmzgv/njS9V7MuvZivFxPKcy6L9U5zJ
C/GItmv07UriYoSwT4mqBFTQVAf00dKUVXelDKpIsvJPb54/s8ZUVV+xSruefoRW
l7FHDWgu2Q1tmHLA/G7oIKI6PVUmL/CtgR5eRGPzOKm/c8Waq2XIsgshugvBkf6S
FlQWQ7BOQhxDnHBWUpYv/4P41F7NXXXeuAdCqkC5qfgUp4QdoMM=
=Vv23
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 27 Jun 2019 13:00
(name . Leo Famulari)(address . leo@famulari.name)
87r27evlwa.fsf@gnu.org
Leo Famulari <leo@famulari.name> skribis:

Toggle quote (14 lines)
> On Thu, Jun 27, 2019 at 05:20:21PM +0200, Ludovic Courtès wrote:
>> We had a “bug report” at
>> <https://distrowatch.com/weekly.php?issue=20190624#guixsd>, which may be
>> due to the same issue:
>>
>> The first time I loaded Guix the boot process took an unusually long
>> time. At one point the system appeared to lock up for about five
>> minutes before continuing. In the end, from boot menu to graphical
>> login screen, the start-up time totalled about ten minutes.
>
> Perhaps, but if the reason for the slowness on their first boot was a
> suboptimal /dev/hwrng source, I would expect it to be equally slow for
> each boot, since we unconditionally read 64 bytes each time.

Perhaps VirtualBox behaves this way? For instance, the VM was rebooted
but VirtualBox itself was still running, and thus it had a good random
seed to start from on the second boot (does that make sense?). I guess
we should try.

Toggle quote (2 lines)
> They are using an old machine with a spinning disk, so who knows...

Still, what else could be taking this long?

Thanks,
Ludo’.
R
R
Robert Vollmert wrote on 27 Jun 2019 23:47
(name . Leo Famulari)(address . leo@famulari.name)
EA773339-2CC9-486E-99B8-A2E71B34467E@vllmrt.net
Toggle quote (6 lines)
> On 27. Jun 2019, at 21:03, Leo Famulari <leo@famulari.name> wrote:

> Perhaps, but if the reason for the slowness on their first boot was a
> suboptimal /dev/hwrng source, I would expect it to be equally slow for
> each boot, since we unconditionally read 64 bytes each time.

It’s 512 bytes, not that that should fundamentally change anything.
L
L
Leo Famulari wrote on 28 Jun 2019 10:24
(name . Robert Vollmert)(address . rob@vllmrt.net)
20190628172401.GA17073@jasmine.lan
On Fri, Jun 28, 2019 at 08:47:35AM +0200, Robert Vollmert wrote:
Toggle quote (7 lines)
> > On 27. Jun 2019, at 21:03, Leo Famulari <leo@famulari.name> wrote:
> > Perhaps, but if the reason for the slowness on their first boot was a
> > suboptimal /dev/hwrng source, I would expect it to be equally slow for
> > each boot, since we unconditionally read 64 bytes each time.
>
> It’s 512 bytes, not that that should fundamentally change anything.

Oh right, my bad. It's been a while...

Anyways, this should either work immediately or fail. Aside from
getrandom(2), which we aren't using here, nothing related to this stuff
should ever block, and if it does then it's a bug we need to work
around.

So, I suggest we add a 1 second timeout to this read.

I can work on that next week.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAl0WTSsACgkQJkb6MLrK
fwg/Fw//TuhAY/itosOCYb0BXcYPmNwKHSNM0BpI5nZk1v7vbyUTlEO2Hvr11ST2
sbuAyvwvD7CER2dNp2ep9YeSGQ+jh2f0ZV/FI/VlSJo3pu53wCvPndwaJWfuUl+D
1NI4v7m4Zgl4ZUnQRdcxaGHBf/waw0z3uRXK5lIxMQBB5895Bt/REkxLuz6E8Jmq
PJw86Wofhl6gR4CqznEv8GWraaNQvJmQxGMYAuENyxP+HTrtUS9BB46X7sOLO2jR
SXMmp9UWDddsCs3FXEMxbnGZXVxLgwmY2NVVlNDU5dcrKy4qtwnAg73PriLT0XXB
UXD2dWk6oZv/O7zLibsKacpZ5+dIoamyH+Y9fjGfGhmohVdYgYdB82I2cZw7OcYh
D9RdcIKU1b+N56i+zVJirXOPg5iLDv+nMG6xJuo52JucH2HVhY4RNux2OTaUQxPo
pnHj4iKYYDJ8+JpA/1DhD0L3DZdigLSqFWmRAkAwrXCvZMotl5oOxwBozlcdNR6M
Oa11OrNUdL29G4Bo9VMNLZWgd8Mcpb6HAUfU/kzM4e6IauUFcakvKF+v8otwujUO
fYSuim286GefG85PEJDxS7ak7G1LslrjVts8J/4CyQ5FYlvJ9TkG/Uh8dGA+M8bv
bk96AOQxRyyF/j/Y3Pll9U8ltdr+vhU8DlOWZRihct5FYmid1Gk=
=//G7
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 11 Jul 2019 10:44
(name . Robert Vollmert)(address . rob@vllmrt.net)
20190711174455.GA30457@jasmine.lan
On Fri, Jun 28, 2019 at 01:24:01PM -0400, Leo Famulari wrote:
Toggle quote (4 lines)
> So, I suggest we add a 1 second timeout to this read.
>
> I can work on that next week.

I did try working on this, after reading the code in (guix scripts
offload (call-with-timeout)).

But, I couldn't make it work at all — it always fails, with all the
services depending on urandom-seed-service failing, breaking the boot.

I don't know how to debug or work interactively in this part of the
system.

Can anybody help?
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAl0ndZQACgkQJkb6MLrK
fwj4mQ//So6Z5OLmFEBI0QRaB1NuH1t12FKqGucuQvtuWPIWr9m1sreYDgHMk5oY
35b7p74t3tasrD8B8ePI2kuKvLX7+rIORPXlARIBLtSvojmXTzpaslBr+FiIxzXS
kFoLEFr/aT3BpxqVL0I3GG+ppz64B8aMUWcWRcFNQkUsg/FZttEx00AQ3dDrC8w3
SSTgsVhWArIt1C8Ypr0Va5ALok6LMIBPa78PdDUS6W5sGXsskAjc+InAG8OKD/0w
hOtCLjwCTCTETElwHpDN1lKsINvvDWFpoqXiwzzcVlDp+7XONXAHdGlaq+b3PIGw
7doOXFiTvaTNLqNRKfXJg2TRFTcrWEU8vmoNw/Stvyf2QeCDFtRoZ1hLbauYjzsJ
+fJbrn80VZrEhIvQu/3ZZhjI8jTX81i/VvjxWKrXetRvgsb6WLL2s+L7O9BG8iRk
Bbyork1OjvXBv+Up0PKbDwx+rLDAvlFrrrxd1G4eVgwYAsHB8TdRb/8sfoclhIUa
IDevyOr1MyVQHSbdn8iV2ag0Gbq9oAxMnk6l3p2p62Hv4r//ZpLfjVM01xC5Bvbe
W8GoH2YJuFzylEluJlvPcO3LauqlXvbWUaRoTZ3BrIOdPtrbNrXCJJw/IZoLcOCr
wu/7Phf4Teq0tI22VY4PX4Q+OaGwLyLmdajJwspLGHH+dlEFybg=
=gN/V
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 11 Jul 2019 14:33
(name . Leo Famulari)(address . leo@famulari.name)
87k1contnw.fsf@gnu.org
Hi Leo,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (8 lines)
> On Fri, Jun 28, 2019 at 01:24:01PM -0400, Leo Famulari wrote:
>> So, I suggest we add a 1 second timeout to this read.
>>
>> I can work on that next week.
>
> I did try working on this, after reading the code in (guix scripts
> offload (call-with-timeout)).

The ‘start’ method of the ‘urandom-seed’ Shepherd service runs in PID 1,
so we certainly don’t want to fiddle with SIGALRM in that context, which
is what ‘call-with-timeout’ does.

Instead, I think we should use ‘select’ with a timeout:

(call-with-input-file "/dev/hwrng"
(lambda (port)
(match (select (list port) '() '() 3)
…)))

I think we can then use ‘get-bytevector-n!’, assuming it doesn’t block
if less than COUNT bytes are available (I’m not sure this is the case.)

HTH!

Ludo’.
R
R
Robert Vollmert wrote on 17 Jul 2019 14:04
related article (Debian)
(address . 36380@debbugs.gnu.org)
B4E22190-D378-45C8-A2B8-DC7D59EF9B52@vllmrt.net
Just ran across this article about Debian dealing with similar issues.


One of the suggested work-arounds is to rely on virtio_rng on
virtual machines, but it seems Guix already uses that on my machine,
so perhaps it doesn’t help:

rob@garp ~$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio_rng.0
rob@garp ~$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio_rng.0
B
B
Brice Waegeneire wrote on 22 Mar 2020 01:43
Re: bug#36380: service urandom-seed takes too long on boot
(address . 36380@debbugs.gnu.org)
a24b84c858011117fd9ea7129af7232c@waegenei.re
Hello,

It would be nice if we could reproduce this issue.

Robert Vollmert <rob@vllmrt.net> writes:
Toggle quote (4 lines)
> Just ran across this article about Debian dealing with similar issues.
>
> https://daniel-lange.com/archives/152-hello-buster.html

This article has been updated since then with a section[0] about a fix
authored by Linus[1][2] and merged in Linux 5.4. The gist of it that now
`getrandom()' will actively try to collect entropy in early boot, if it
is missing, by using the CPU jitter. The Debian wiki is saying the
same[3].

Since we are using actually using Linux-libre 5.4 as the default kernel
this issue should probably be closed.

[0]:
[1]:
[2]:

Brice.
L
L
Leo Famulari wrote on 22 Mar 2020 13:19
(name . Brice Waegeneire)(address . brice@waegenei.re)(address . 36380@debbugs.gnu.org)
20200322201919.GC16716@jasmine.lan
On Sun, Mar 22, 2020 at 08:43:33AM +0000, Brice Waegeneire wrote:
Toggle quote (5 lines)
> This article has been updated since then with a section[0] about a fix
> authored by Linus[1][2] and merged in Linux 5.4. The gist of it that now
> `getrandom()' will actively try to collect entropy in early boot, if it
> is missing, by using the CPU jitter. The Debian wiki is saying the same[3].

The issue here is not related to getrandom() or our kernel. I think the
bug is still relevant.

The Guix system unconditionally reads from /dev/hwrng if it exists, and
there is no reason for that to take a noticeable amount of time.

But this bug report revealed that some VPS providers have a broken
deployment that does cause delays. Who knows how they are feeding
/dev/hwrng... they would not reply to my questions.

It doesn't really matter though, the problem is ours to fix.

We need to make this read time out after a second, but in the past I
could not figure out how to do this without crashing the system (I'm not
a strong Schemer).

Help is still wanted!
S
S
Stefan wrote on 27 Dec 2020 07:00
service urandom-seed takes too long on boot
(address . 36380@debbugs.gnu.org)
2C14BF51-2755-4315-AC75-26F71F93884D@vodafonemail.de
Hi!

I’m running Guix in qemu on a NAS. The boot takes sometimes more than 30 minutes, probably waiting to start the urandom-seed service.

Guix is using virtio_rng:

stefan@guix ~$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio_rng.0
stefan@guix ~$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio_rng.0
stefan@guix ~$ guix describe
Generation 1 26. Dezember 2020 15:06:11 (aktuell)
guix 4969b51
Branch: master
Commit: 4969b51d175497bfcc354c91803e9d70542b7113


This may be relevant information from dmesg:

[ 0.194324] random: get_random_u64 called from __kmem_cache_create+0x30/0x460 with crng_init=0
[ 3.271767] random: fast init done
[ 3.497369] random: crng init done
[ 21.228829] shepherd[1]: Service file-systems has been started.
[ 21.243838] shepherd[1]: Service user-homes has been started.
[ 2182.735965] shepherd[1]: Service urandom-seed has been started.
[ 2182.737229] shepherd[1]: Service user-processes has been started.

Sometimes the urandom-seed service takes “just” 200 seconds – still a lot.

Interestingly during this time-out the system can’t be pinged, the networking with dhclient doesn't seem to be done.

The Guix installer iso is not using the urandom-seed service and does not suffer from this delay.


The host kernel and qemu are rather old:

~$ uname -a
Linux aaaaaaaa 4.4.59+ #25426 SMP PREEMPT Mon Dec 14 18:48:50 CST 2020 x86_64 GNU/Linux synology_apollolake
~$ /usr/local/bin/qemu-system-x86_64 --version
QEMU emulator version 2.12.1 (-dirty)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers


Qemu is invoked with these arguments concerning random:

-cpu host,+smap,+rdseed,+erms,+smep,+fsgsbase,+3dnowprefetch,+rdtscp,+pdpe1gb,+rdrand,+osxsave,+xsave,+tsc-deadline,+movbe,+x2apic,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x1c

The full qemu command is huge. I can provide it on request.


Bye

Stefan
L
L
Leo Famulari wrote on 27 Dec 2020 15:09
(name . Stefan)(address . stefan-guix@vodafonemail.de)(address . 36380@debbugs.gnu.org)
X+kURC9LmmFz5Ks7@jasmine.lan
On Sun, Dec 27, 2020 at 04:00:23PM +0100, Stefan wrote:
Toggle quote (4 lines)
> Qemu is invoked with these arguments concerning random:
>
> -cpu host,+smap,+rdseed,+erms,+smep,+fsgsbase,+3dnowprefetch,+rdtscp,+pdpe1gb,+rdrand,+osxsave,+xsave,+tsc-deadline,+movbe,+x2apic,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x1c

What does the argument "filename=/dev/random" do? Does it use the host's
/dev/random to provide entropy to the QEMU guest?
S
S
Stefan wrote on 27 Dec 2020 15:28
(name . Leo Famulari)(address . leo@famulari.name)(address . 36380@debbugs.gnu.org)
6A711ED5-B7D9-4276-88C4-08C7ADE2DFC0@vodafonemail.de
Hi Leo!

Toggle quote (3 lines)
> What does the argument "filename=/dev/random" do? Does it use the host's
> /dev/random to provide entropy to the QEMU guest?

Yes, see [1]:

“-object rng-random,id=id,filename=/dev/random
Creates a random number generator backend which obtains entropy from a device on the host. The id parameter is a unique ID that will be used to reference this entropy backend from the virtio-rng device. The filename parameter specifies which file to obtain entropy from and if omitted defaults to /dev/urandom.”


Bye

Stefan


L
L
Leo Famulari wrote on 28 Dec 2020 18:51
(name . Stefan)(address . stefan-guix@vodafonemail.de)(address . 36380@debbugs.gnu.org)
X+qZp6UZ9db5yt19@jasmine.lan
On Mon, Dec 28, 2020 at 12:28:09AM +0100, Stefan wrote:
Toggle quote (3 lines)
> “-object rng-random,id=id,filename=/dev/random
> Creates a random number generator backend which obtains entropy from a device on the host. The id parameter is a unique ID that will be used to reference this entropy backend from the virtio-rng device. The filename parameter specifies which file to obtain entropy from and if omitted defaults to /dev/urandom.”

I see, so there is the problem.

It should either be changed to "filename=/dev/urandom", or the QEMU
rng-random mechanism should be disabled.

We still need to implement a timeout to workaround this kind of
misconfiguration... help wanted :)
R
R
raid5atemyhomework wrote on 7 Feb 2021 07:23
service urandom-seed takes too long on boot
(name . 36380@debbugs.gnu.org)(address . 36380@debbugs.gnu.org)
WNVyEQuIt5aHwSlkxpYNZx49vGxO5K8ABy-Vd4_g98Pr5B-IHsJmu5qlsnAq2z_YSuJ8l5giKdR0NcuUMsQzUX6OJ6Hb7D-Bjcb3aR9WmuI=@protonmail.com
```scheme
(define (get-bytevector-n-timed port count max-time)
"Read COUNT octets from PORT, blocking as necessary and return a
bytevector containing the octets read, and taking no more than
MAX-TIME seconds. If fewer bytes are available, a bytevector
smaller than COUNT is returned."

(define (get-time)
(let* ((pair (gettimeofday))
(secs (car pair))
(usecs (cdr pair)))
(+ secs (* 0.000001 usecs))))

(let* ((start-time (get-time))
(end-time (+ start-time max-time))
(buf (make-bytevector count)))
(let loop ((offset 0))
(let ((current-time (get-time)))
(cond
((= offset count)
buf)
((>= current-time end-time)
(let ((newbuf (make-bytevector offset)))
(bytevector-copy! buf 0 newbuf 0 offset)
newbuf))
(else
(let* ((result (select (list port) '() '() (- end-time current-time)))
(readable? (not (null? (car result)))))
(if readable?
(begin
;; read only one byte at a time, as we cannot be sure
;; that the given port will have more than one byte
;; available and that ports will not block if we ask
;; for more than one byte.
(get-bytevector-n! port buf offset 1)
(loop (+ offset 1)))
(loop offset)))))))))
```
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 36380@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 36380
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch