Low entropy in VMs? Does HAVEGED make sense within a Xen VM?

[sudod...@gmail.com]

Recently I noticed that in the Archlinux template the HAVEGED entropy daemon is not enabled per default. This leads to a very low entropy inflow into VMs. Normally Linux will gather entropy from interrupts from keyboard, mouse and possibly other devices. Since there are no hardware devices connected to appvms this source of entropy is not reliable. In fedora-23 template haveged.service tries to solve that problem. But can it really?
As far as I know HAVEGED uses volatile hardware states to feed /dev/random. How many of those states are still available in a VM? My guess: the CPU clock and on never Intel processors RDRAND. Any more? The CPU clock's entropy may not be very high and RDRAND might not be available on older CPUs. (Some people also don't fully trust RDRAND).
A unpredictable /dev/random or /dev/urandom can be crucial for security (key generation). Does Qubes or Xen somehow handle that problem?

[Eric Shelton]

I don't have a direct answer to your question.  However, I will note it is a long-recognized problem for Xen VMs.  It looks like KVM addressed it via virtio-rng, but that no similar PV interface was instituted for Xen.  It is possible that the Linux kernel has evolved to gather entropy from other places in recent years (there are all kinds of ideas that go beyond using interrupts, such as the state of the instruction pipeline).

Anyways, you might want to investigate what is being done by Xen users, as I imagine there is a solution, or it has been addressed in some manner, out there.  There are a lot of EC2 instances out there that probably like to have a decent entropy pool, for example.

Eric

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

See related ticket[1] for more discussion about this.

[1] https://github.com/QubesOS/qubes-issues/issues/673

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWtOJXAAoJENuP0xzK19csBP4H/2Bnv8hQHQUX/ocAwPZGD5Qm
TS18600tTXSpYYyuWdjCCGiYWHXkRFyvXY3nVBQR1k45Uh9Rw4GSjjwWCy2Rif5Y
hcTXKXDFycZf8j78mJZyckDPLKOXjNO725hdpdsnCRHP3PdO5zSP782IWMEAdOAM
Y1jP/SDd6Vkvzj7UJXto464GOuFinCq/to9rUodd1J/ByT26fcVgx17sx6djPd4D
yithzjWYJfID4hqyGir0YPzd8128xghW/3UtEqrse3DLsOXS1EYSQqaYat6v7NHy
FbKR/lMCOjp/LZHfgI+xFsx1H13ojawR68S9jQUA450zm3NkS9bfJDphNUC0JW4=
=8ERJ
-----END PGP SIGNATURE-----

[Dimitri]

 
Ok. At the first glimpse this looks promising https://github.com/mirage/xentropyd (posted by adrelanos half an hour ago in https://github.com/QubesOS/qubes-issues/issues/673).
The approach is to send entropy from dom0's /dev/urandom to the VMs. This has not yet been adopted in Qubes. Right?
Haveged seems to be the simplest solution but I fear it's hard to verify that it does a good job within a VM.

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dimitri:

>
>
> Am Freitag, 5. Februar 2016 18:56:47 UTC+1 schrieb Marek
> Marczykowski-Górecki:
>>

> Ok. At the first glimpse this looks promising
> https://github.com/mirage/xentropyd (posted by adrelanos half an hour
> ago in https://github.com/QubesOS/qubes-issues/issues/673). The
> approach is to send entropy from dom0's /dev/urandom to the VMs. This
> has not yet been adopted in Qubes. Right?

It has, see [2] and [3].

> Haveged seems to be the
> simplest solution but I fear it's hard to verify that it does a good
> job within a VM.

[2]: https://github.com/QubesOS/qubes-core-agent-linux/commit/0ffa7466787a8177e46e7389c26fad227435b10b
[3]: https://github.com/QubesOS/qubes-core-admin/commit/912d4c144730b361672c7dc7e6bbc0e5c8f4bccf
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWtTHcAAoJEOSsySeKZGgWVN0P/js2TiiioA53+GL/yG381Iab
Q27Q+lEGT9ISSc2XZhKFjOkX4UO3o8aDokYDvW6IDnNYGYkANTlLTSv6Zw743Rbb
n0oy9IMK8legBJCMbdefToxW8CmjUaUJPLEI7y3n8BmHqms8rvmGjkjxK5y6wd3j
osVOwlq5utGm5KKkqWwBbuV3/sppBmt8FJoIR2HrRY75OX2JaFkB7i+BexH8jLU/
QezsIc+UvxjgkiBszC36mhpg4pG7qfanyIGHBi9VIJppNnmxoO4FRuCoMweEM97G
ony91kGYnKrLRQ41hgjL46D9nQCEVPTlwXPAo5wEICdZHDDX0NoTSGSj35k0Pko5
iyAE+QgrzRTtt3c60kWDvF9BDlbKyCG2RaRbpQzaxtpNCqNUfA5JNSoyM783SZ2W
/qLI6IzXNCiPcuAa9Oe+VDmOlt8YMHQZFst/bHzyRFC48x2cYwyBnXavgf6Zd+CV
KPFskWOFYueNPUAOTaoqj1smvGu/xiUtS+FIDBkn8s9AVxREwAZPg7kRb+zwzyUW
bcSLxDfl2EGymfrn8jHLG+XwWjhDPrv6zaC73uin56qbD8Cj6I4Urnih1NmXQYrQ
rfBePgIcFZIiDsGgmNYkJf4/EeTcPuqgX9AnL94uqrZ36QUdnWJsJcNH8nzUgrDC
0e3k6FpJUwjSeHdt1Pf2
=gHkR
-----END PGP SIGNATURE-----

[Chris Laprise]

> --

IIRC, EC2 uses proprietary modifications. This could be one of the
features that Amazon doesn't share.

Its also concerning that, especially for vms isolated from the net (no
netvm setting), being inside a vm by its very nature might create IO
patterns that are more regular. Moreso if you don't use spinning disks
for storage. I have to wonder if this degrades an OS's ability to
collect entropy.

Chris