Use /qubes-random-seed

[talex5]

QubesDB provides us with some extra entropy in /qubes-random-seed. If we configure a Qubes unikernel with a random number generator, it should probably mix this in somehow.

[cfcs]

That sounds very sensible!

Do you have any suggestions regarding where it might make sense to patch this in?

• mirage_impl_random.ml / mirage_impl_qubesdb
  • seems to me that we face the problem that random doesn't mean there'll be a qubesdb device, and vice versa. OTOH if mirage_impl_random is required and compiled for the qubes target it seems reasonable to depend on a qubesdb device.
• mirage-entropy, not sure if it makes sense to touch this, but mentioned it just in case.

[hannesm]

imho this should go into mirage-entropy (likely a mirage-entropy qubes variant should be created that mixes the random-seed (is this constant, or does it change over the lifetime?)) -- mirage-entropy is nowadays used by all (mirage-random-stdlib/nocrypto) RNG with MirageOS (there's only ever one which is seeded and used by the unikernel)

[cfcs]

The entry is there to seed the CSPRNG of VMs at early boot before they have been able to collect their own entropy. The equivalent in Linux is /var/lib/systemd/random-seed (maintained by the systemd-random-seed service). In OpenBSD they have /etc/random.seed. In FreeBSD there's /boot/entropy and maybe /entropy.

• It is read when qubes-core-early calls qubes-random-seed.sh which then calls reload_random_seed (what a useless indirection) which then reads the qubesdb entry before removing it from qubesdb.
  • We should probably also remove the entry after reading it.
• I wonder if the VM should also save its seed there ?
• For periodic reseeding I'm not sure what the best approach is, but I noted that there's a /etc/qubes-rpc/qubes.GetRandomizedTime RPC service that seems to be available by default and can be accessed like:

  qrexec-client-vm dom0 qubes.GetRandomizedTime
  1563118390.075431142

  This provides us with the output of shuf -i0-1 ; shuf -i0-180; shuf -i0-999999999 all seeded by /dev/random from the host. So that should gives us roughly log2(1+1) + log2(1+180) + log2(1+999999999) (ie ~37) bits of entropy.

[hannesm]

I asked @marmarek about /qubes-random-seed semantics, and it is written once by the host system, i.e. no need to (a) write something from the guest side to that key and (b) read the value periodically.