Description of problem: Enhance "out of the box" RNG built-in entropy, as its too small. While looking at our present entropy for HE-VM from https://bugzilla.redhat.com/show_bug.cgi?id=1368027#c11, compared to those received from rng-tools from https://bugzilla.redhat.com/show_bug.cgi?id=1357246#c5, I'd like to ask for an improvement for too small entropy for HE-VM. There is a solution documented here https://access.redhat.com/solutions/19866 on how to increase the entropy pool without using a keyboard or mouse, but I would like to ask for the improvement right out of the box, so no additional actions would be required. Version-Release number of selected component (if applicable): Engine: rhevm-setup-plugins-4.1.0-1.el7ev.noarch rhevm-dependencies-4.1.0-1.el7ev.noarch rhevm-doc-4.1.0-2.el7ev.noarch rhev-guest-tools-iso-4.1-3.el7ev.noarch rhevm-4.1.0.4-0.1.el7.noarch rhevm-branding-rhev-4.1.0-0.el7ev.noarch Linux version 3.10.0-514.6.1.el7.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Sat Dec 10 11:15:38 EST 2016 Linux 3.10.0-514.6.1.el7.x86_64 #1 SMP Sat Dec 10 11:15:38 EST 2016 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 7.3 (Maipo) Hosts: rhvm-appliance-4.1.20170126.0-1.el7ev.noarch ovirt-imageio-common-1.0.0-0.el7ev.noarch ovirt-hosted-engine-ha-2.1.0.1-1.el7ev.noarch ovirt-hosted-engine-setup-2.1.0.1-1.el7ev.noarch ovirt-engine-sdk-python-3.6.9.1-1.el7ev.noarch ovirt-host-deploy-1.6.0-1.el7ev.noarch ovirt-vmconsole-1.0.4-1.el7ev.noarch ovirt-node-ng-nodectl-4.1.0-0.20170104.1.el7.noarch libvirt-client-2.0.0-10.el7_3.4.x86_64 qemu-kvm-rhev-2.6.0-28.el7_3.3.x86_64 vdsm-4.19.4-1.el7ev.x86_64 sanlock-3.4.0-1.el7.x86_64 ovirt-vmconsole-host-1.0.4-1.el7ev.noarch mom-0.5.8-1.el7ev.noarch ovirt-imageio-daemon-1.0.0-0.el7ev.noarch ovirt-setup-lib-1.1.0-1.el7ev.noarch Linux version 3.10.0-514.6.1.el7.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Sat Dec 10 11:15:38 EST 2016 Linux 3.10.0-514.6.1.el7.x86_64 #1 SMP Sat Dec 10 11:15:38 EST 2016 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux release 7.3 How reproducible: 100% Steps to Reproduce: 1.Deploy HE on a single host, over NFS and add 2 NFS data storage domains to it. 2.Get HE storage_domain auto-imported. 3.Check on host "cat /run/ovirt-hosted-engine-ha/vm.conf | grep random devices={device:virtio,specParams:{source:random},model:virtio,type:rng}" 4.Run on host "time sh -xc 'while true; do dd if=/dev/random of=/dev/null bs=1 count=5; cat /proc/sys/kernel/random/entropy_avail; sleep 1; done' " and after several minutes exit using "ctrl+c" exit sequence. Actual results: # time sh -xc 'while true; do dd if=/dev/random of=/dev/null bs=1 count=5; cat /proc/sys/kernel/random/entropy_avail; sleep 1; done' + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000182068 s, 27.5 kB/s + cat /proc/sys/kernel/random/entropy_avail 23 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 39.3871 s, 0.0 kB/s + cat /proc/sys/kernel/random/entropy_avail 94 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000198586 s, 25.2 kB/s + cat /proc/sys/kernel/random/entropy_avail 30 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 33.2879 s, 0.0 kB/s + cat /proc/sys/kernel/random/entropy_avail 76 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000182515 s, 27.4 kB/s + cat /proc/sys/kernel/random/entropy_avail 105 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000177201 s, 28.2 kB/s + cat /proc/sys/kernel/random/entropy_avail 106 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000182921 s, 27.3 kB/s + cat /proc/sys/kernel/random/entropy_avail 44 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 20.4807 s, 0.0 kB/s + cat /proc/sys/kernel/random/entropy_avail 34 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 25.0991 s, 0.0 kB/s + cat /proc/sys/kernel/random/entropy_avail 93 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000193267 s, 25.9 kB/s + cat /proc/sys/kernel/random/entropy_avail 29 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 32.9122 s, 0.0 kB/s + cat /proc/sys/kernel/random/entropy_avail 69 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000221004 s, 22.6 kB/s + cat /proc/sys/kernel/random/entropy_avail 70 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000227211 s, 22.0 kB/s + cat /proc/sys/kernel/random/entropy_avail 106 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000184224 s, 27.1 kB/s + cat /proc/sys/kernel/random/entropy_avail 44 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 17.5625 s, 0.0 kB/s + cat /proc/sys/kernel/random/entropy_avail 35 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 ^C3+0 records in 3+0 records out 3 bytes (3 B) copied, 1.67787 s, 0.0 kB/s real 3m5.470s user 0m0.016s sys 0m0.050s Expected results: Entropy should be much greater. Additional info:
Is the hosted-engine different than any other VM? I'm not sure I understand the bug. I'm not sure it's a real issue, with more CPUs with HWRNG coming in.
(In reply to Yaniv Kaul from comment #1) > Is the hosted-engine different than any other VM? > I'm not sure I understand the bug. I'm not sure it's a real issue, with more > CPUs with HWRNG coming in. HE-VM not much differs from other VMs, though it has several different parameters, for example entropy might be gained also from I/O to storage or PCI interrupts, really depends on implementation, and regular VMs might have a different storage types than HE or lesser CPU intensity. The core principle is the same in general for all VMs. I simply see that entropy number is too small and rising well over the time, but lessened rather than growing in the entropy pool, if compared to results received from rng-tools on the same VM. We may test the entropy for it's quality based on dieharder tool from here: https://www.phy.duke.edu/~rgb/General/dieharder.php I would not consider this as a problem, rather as enhancement.
> I would not consider this as a problem, rather as enhancement. Then why the severity hard? That is reserved for issues that are preventing the customer from using the system properly. And you should mark the bug as RFE in that case too. Moreover, I do not really see how the hosted engine agent can help there, this should probably be an appliance bug instead. The agent already adds a RNG device to the VM by default (thanks to https://bugzilla.redhat.com/show_bug.cgi?id=1368027) and that is as far as it can go by itself.
Corrected to RFE, thanks. High was set as the entropy is really small (entropy pool being purged really fast,and should recover faster) and might prevent entropy based applications from normal functionality. Opened on agent forth to https://bugzilla.redhat.com/show_bug.cgi?id=1368027
To be honest this is probably less of an issue for the majority of the users. For now we'll keep this RFE to see if there's any specific need for it.
I would ask for an opinion from the Virt side of the house. Last time we touched RNG devices, we were told to use /dev/urandom. I do not see how we can influence the kernel entropy pools in any way or if it actually makes any sense.
As martin said, using /dev/urandom is the preferred way of feeding entropy into the VM. The step 3 says "...{source:random}...", the only thing is to make sure urandom is used (aka source:urandom).
(In reply to Martin Polednik from comment #7) > As martin said, using /dev/urandom is the preferred way of feeding entropy > into the VM. > > The step 3 says "...{source:random}...", the only thing is to make sure > urandom is used (aka source:urandom). I think this is done in 4.2 already. Simone?
(In reply to Yaniv Kaul from comment #8) > I think this is done in 4.2 already. Simone? We cannot explicitly set it with ovirt_vms ansible module used in the node zero deployment but /dev/urandom is the default there and I verified that it's correctly set for the hosted-engine VM.
At the time, I asked to use /dev/urandom in some script called by engine-setup and mperina rejected this, see bug 1319827. Personally I am still not convinced, but I think that telling the vm to use the host's /dev/urandom as its entropy source is cheating. Programs inside the vm that want to use /dev/random, should be able to use it, without having to think about whether the data from it is really random or not, and to what extent. Programs that can get by with using /dev/urandom directly, should do that. Martin - what do you think?
(In reply to Yedidyah Bar David from comment #10) > At the time, I asked to use /dev/urandom in some script called by > engine-setup and mperina rejected this, see bug 1319827. > > Personally I am still not convinced, but I think that telling the vm to use > the host's /dev/urandom as its entropy source is cheating. Programs inside > the vm that want to use /dev/random, should be able to use it, without > having to think about whether the data from it is really random or not, and > to what extent. Programs that can get by with using /dev/urandom directly, > should do that. It's not directly - it's feeding it to virtio-rng, which is feeding it to the guest's /dev/random (and /dev/urandom). It has really no other way of randomness... And the host probably has better sources. > > Martin - what do you think?
I am not a security expert. From the little I understand about /dev/random vs /dev/urandom, the main problem with using the latter for security-related things, is early during boot. Then, /dev/random will block, but /dev/urandom will happily provide data that is based on almost no entropy, potentially. Now, suppose that you reboot a host, and immediately start HE deploy. With current plan, you feed the VM with what might be very low quality random data, and tell it that it's high-quality. That's lying. If some program (or a user of that program) decides that the quality of /dev/urandom is enough, under certain circumstances, why not use it directly?
BTW, to solve current bug, I suggest to: 1. Provide other means, but do not enable them, unless they are considered safe, by the security community. E.g. install in the appliance egd, haveged, stuff like that. If we want, even test in the beginning of HE deploy if we have low entropy, and prompt the user: It seems like the machine has low entropy. Please see $URL for more details. Please choose one of: 1. Continue without doing anything. Deploy will likely be slow, taking minutes to tens of minutes more than the other options 2. Start haveged. Fast, New, Security is still investigated 3. Start egd. Old, ? etc. 2. Reconsider using /dev/urandom directly where it makes sense, see e.g. already-linked bug 1319827.
(In reply to Yedidyah Bar David from comment #12) > Now, suppose that you reboot a host, and immediately start HE deploy. That point is way later than what "early boot" refers to. From https://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939 "if the machine booted up to a point where it has begun having some network activity then it has gathered enough physical randomness to provide randomness of high enough quality for all practical usages (I am talking about Linux here;..." Additional sources of information why we should prefer /dev/urandom: https://www.2uo.de/myths-about-urandom/ https://pthree.org/2014/07/21/the-linux-random-number-generator/ > 2. Reconsider using /dev/urandom directly where it makes sense, see e.g. already-linked bug 1319827. +1
I've created BZ1540907 and BZ1540909 to fix that issue in engine and aaa-jdbc
Looks much better now on these components: Works for me on these components: ovirt-hosted-engine-ha-2.2.7-1.el7ev.noarch ovirt-hosted-engine-setup-2.2.13-1.el7ev.noarch rhvm-appliance-4.2-20180202.0.el7.noarch Linux 3.10.0-861.el7.x86_64 #1 SMP Wed Mar 14 10:21:01 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 7.5 (Maipo) On engine: nsednev-he-1 ~]# time sh -xc 'while true; do dd if=/dev/random of=/dev/null bs=1 count=5; cat /proc/sys/kernel/random/entropy_avail; sleep 1; done' + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000299757 s, 16.7 kB/s + cat /proc/sys/kernel/random/entropy_avail 1159 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000292873 s, 17.1 kB/s + cat /proc/sys/kernel/random/entropy_avail 1159 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000283044 s, 17.7 kB/s + cat /proc/sys/kernel/random/entropy_avail 1096 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000259027 s, 19.3 kB/s + cat /proc/sys/kernel/random/entropy_avail 1097 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000291758 s, 17.1 kB/s + cat /proc/sys/kernel/random/entropy_avail 1098 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000258489 s, 19.3 kB/s + cat /proc/sys/kernel/random/entropy_avail 1099 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000304135 s, 16.4 kB/s + cat /proc/sys/kernel/random/entropy_avail 1100 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000272609 s, 18.3 kB/s + cat /proc/sys/kernel/random/entropy_avail 1101 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000294244 s, 17.0 kB/s + cat /proc/sys/kernel/random/entropy_avail 1102 + sleep 1 ^C real 0m8.656s user 0m0.021s sys 0m0.047s On ha-host: [root@alma03 ~]# cat /run/ovirt-hosted-engine-ha/vm.conf | grep random devices={alias:rng0,specParams:{source:urandom},deviceId:b8e60f7a-46f5-491d-a140-48b13ded816f,address:{type:pci,slot:0x09,bus:0x00,domain:0x0000,function:0x0},device:virtio,model:virtio,type:rng} [root@alma03 ~]# time sh -xc 'while true; do dd if=/dev/random of=/dev/null bs=1 count=5; cat /proc/sys/kernel/random/entropy_avail; sleep 1; done' + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000200491 s, 24.9 kB/s + cat /proc/sys/kernel/random/entropy_avail 3466 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000207446 s, 24.1 kB/s + cat /proc/sys/kernel/random/entropy_avail 3402 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000213126 s, 23.5 kB/s + cat /proc/sys/kernel/random/entropy_avail 3403 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000207804 s, 24.1 kB/s + cat /proc/sys/kernel/random/entropy_avail 3406 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000206678 s, 24.2 kB/s + cat /proc/sys/kernel/random/entropy_avail 3407 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000206152 s, 24.3 kB/s + cat /proc/sys/kernel/random/entropy_avail 3408 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000213566 s, 23.4 kB/s + cat /proc/sys/kernel/random/entropy_avail 3408 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000217206 s, 23.0 kB/s + cat /proc/sys/kernel/random/entropy_avail 3409 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000198777 s, 25.2 kB/s + cat /proc/sys/kernel/random/entropy_avail 3413 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000209357 s, 23.9 kB/s + cat /proc/sys/kernel/random/entropy_avail 3414 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000208308 s, 24.0 kB/s + cat /proc/sys/kernel/random/entropy_avail 3414 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000203304 s, 24.6 kB/s + cat /proc/sys/kernel/random/entropy_avail 3414 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000204641 s, 24.4 kB/s + cat /proc/sys/kernel/random/entropy_avail 3414 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000206264 s, 24.2 kB/s + cat /proc/sys/kernel/random/entropy_avail 3351 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000193288 s, 25.9 kB/s + cat /proc/sys/kernel/random/entropy_avail 3355 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000196284 s, 25.5 kB/s + cat /proc/sys/kernel/random/entropy_avail 3356 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000206408 s, 24.2 kB/s + cat /proc/sys/kernel/random/entropy_avail 3356 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.00020273 s, 24.7 kB/s + cat /proc/sys/kernel/random/entropy_avail 3357 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.00020705 s, 24.1 kB/s + cat /proc/sys/kernel/random/entropy_avail 3357 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000202604 s, 24.7 kB/s + cat /proc/sys/kernel/random/entropy_avail 3360 + sleep 1 + true + dd if=/dev/random of=/dev/null bs=1 count=5 5+0 records in 5+0 records out 5 bytes (5 B) copied, 0.000202932 s, 24.6 kB/s + cat /proc/sys/kernel/random/entropy_avail 3297 + sleep 1 ^C real 0m20.512s user 0m0.024s sys 0m0.071s
Closing old RFEs. Please reopen if needed. Patches are welcome.