Discussion:
Seeding the Linux RNG at first boot
(too old to reply)
Leo Famulari
2017-12-06 18:27:11 UTC
Permalink
Raw Message
FWIW if you control the hypervisor, you can send something along the
qemu -device virtio-rng-pci,bus=pci.0,addr=0x1e,max-bytes=1024,period=1000
to feed the guest with entropy from the host through virtio, up to 1kB/s.
Exactly, this is along the lines of what I'm thinking for `guix system
vm`.

On the guest side, we would extend urandom-seed-service to also draw on
/dev/hwrng, which is where virtio-rng-pci makes the data from the host
available.

Currently there is the rngd-service-type, but that is doing something
slightly different. Using /dev/hwrng to seed urandom could be done
whenever it's enabled in the kernel.

I have an idea for another improvement: to add an argument like
"--entropy-seed=" to `guix system` that could place the value in
'/var/lib/random-seed', where it would be used on first boot.

Thoughts?
Ludovic Courtès
2017-12-07 21:07:38 UTC
Permalink
Raw Message
Post by Leo Famulari
FWIW if you control the hypervisor, you can send something along the
qemu -device virtio-rng-pci,bus=pci.0,addr=0x1e,max-bytes=1024,period=1000
to feed the guest with entropy from the host through virtio, up to 1kB/s.
Exactly, this is along the lines of what I'm thinking for `guix system
vm`.
On the guest side, we would extend urandom-seed-service to also draw on
/dev/hwrng, which is where virtio-rng-pci makes the data from the host
available.
Maybe ‘virtualized-operating-system’ in (gnu system vm) could
automatically customize ‘rngd-service-type’ (or add it)?
Post by Leo Famulari
Currently there is the rngd-service-type, but that is doing something
slightly different. Using /dev/hwrng to seed urandom could be done
whenever it's enabled in the kernel.
I have an idea for another improvement: to add an argument like
"--entropy-seed=" to `guix system` that could place the value in
'/var/lib/random-seed', where it would be used on first boot.
We could do that, though I very much prefer the idea of a “backdoor” à
la virtio-rng-pci, because it allows to stick to bit-reproducible images
(well, they’re not bit-reproducible yet I suppose, but let’s not add to
it.)

WDYT?

Ludo’.
Leo Famulari
2017-12-07 23:47:49 UTC
Permalink
Raw Message
Post by Leo Famulari
On the guest side, we would extend urandom-seed-service to also draw on
/dev/hwrng, which is where virtio-rng-pci makes the data from the host
available.
Maybe ‘virtualized-operating-system’ in (gnu system vm) could
automatically customize ‘rngd-service-type’ (or add it)?
Yes, we could do that, although I don't think it's necessary to run a
daemon continuously. It is enough to seed the RNG once.

At the same time we handle the random seed, we could also try reading
from /dev/hwrng and, if the read is successful, copy some bytes into
/dev/urandom. We'd have to try reading and handle failure since we
always create /dev/hwrng regardless of whether the Linux kernel module
is loaded or not.
Post by Leo Famulari
I have an idea for another improvement: to add an argument like
"--entropy-seed=" to `guix system` that could place the value in
'/var/lib/random-seed', where it would be used on first boot.
We could do that, though I very much prefer the idea of a “backdoor” à
la virtio-rng-pci, because it allows to stick to bit-reproducible images
(well, they’re not bit-reproducible yet I suppose, but let’s not add to
it.)
I think it would be most useful for disk images, for which there is no
host.

If one always passes the same value to --entropy-seed, it will not
negatively affect the reproducibility of the image ;)

This would not be something we do for the official release image, but
merely an optional tool.
Ludovic Courtès
2017-12-11 09:16:42 UTC
Permalink
Raw Message
Post by Leo Famulari
Post by Ludovic Courtès
Post by Leo Famulari
On the guest side, we would extend urandom-seed-service to also draw on
/dev/hwrng, which is where virtio-rng-pci makes the data from the host
available.
Maybe ‘virtualized-operating-system’ in (gnu system vm) could
automatically customize ‘rngd-service-type’ (or add it)?
Yes, we could do that, although I don't think it's necessary to run a
daemon continuously. It is enough to seed the RNG once.
At the same time we handle the random seed, we could also try reading
from /dev/hwrng and, if the read is successful, copy some bytes into
/dev/urandom. We'd have to try reading and handle failure since we
always create /dev/hwrng regardless of whether the Linux kernel module
is loaded or not.
OK.
Post by Leo Famulari
Post by Ludovic Courtès
Post by Leo Famulari
I have an idea for another improvement: to add an argument like
"--entropy-seed=" to `guix system` that could place the value in
'/var/lib/random-seed', where it would be used on first boot.
We could do that, though I very much prefer the idea of a “backdoor” à
la virtio-rng-pci, because it allows to stick to bit-reproducible images
(well, they’re not bit-reproducible yet I suppose, but let’s not add to
it.)
I think it would be most useful for disk images, for which there is no
host.
OK, in that case the “backdoor” isn’t an option.
Post by Leo Famulari
If one always passes the same value to --entropy-seed, it will not
negatively affect the reproducibility of the image ;)
This would not be something we do for the official release image, but
merely an optional tool.
Yeah it’d be OK to add this as an option.

When the option is present, ‘guix system’ would hook into the VM
creation code somehow, or to extend ‘activation-service-type’ with code
to create the file.

Maybe we could provide a more generic --copy-file=SOURCE[=DEST] option?
Like --copy-file=./my-seed=/var/lib/random-seed or
--copy-file=$HOME/.ssh/authorized_keys.

Thoughts?

Ludo’.
Leo Famulari
2017-12-11 16:08:45 UTC
Permalink
Raw Message
Post by Leo Famulari
At the same time we handle the random seed, we could also try reading
from /dev/hwrng and, if the read is successful, copy some bytes into
/dev/urandom. We'd have to try reading and handle failure since we
always create /dev/hwrng regardless of whether the Linux kernel module
is loaded or not.
OK.
Okay, I'll work on adding this to the urandom-seed-service.
Post by Leo Famulari
If one always passes the same value to --entropy-seed, it will not
negatively affect the reproducibility of the image ;)
This would not be something we do for the official release image, but
merely an optional tool.
Yeah it’d be OK to add this as an option.
When the option is present, ‘guix system’ would hook into the VM
creation code somehow, or to extend ‘activation-service-type’ with code
to create the file.
Maybe we could provide a more generic --copy-file=SOURCE[=DEST] option?
Like --copy-file=./my-seed=/var/lib/random-seed or
--copy-file=$HOME/.ssh/authorized_keys.
Thoughts?
That sounds good to me. I'll try implementing it.

Loading...