Bug 1421472 - [RFE] Hosted-engine: Enhance "out of the box" RNG built-in entropy, as its too small.
Summary: [RFE] Hosted-engine: Enhance "out of the box" RNG built-in entropy, as its to...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: ovirt-appliance
Classification: oVirt
Component: RFEs
Version: ---
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
: ---
Assignee: Yuval Turgeman
QA Contact: Nikolai Sednev
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-12 14:58 UTC by Nikolai Sednev
Modified: 2018-06-06 12:31 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-06 12:31:28 UTC
oVirt Team: Integration
dfediuck: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 84361 0 master ABANDONED ansible: localvm: enable /dev/urandom on the local vm 2018-06-06 12:33:11 UTC

Description Nikolai Sednev 2017-02-12 14:58:33 UTC
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@x86-030.build.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@x86-030.build.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:

Comment 1 Yaniv Kaul 2017-02-12 15:33:58 UTC
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.

Comment 2 Nikolai Sednev 2017-02-12 15:40:36 UTC
(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.

Comment 3 Martin Sivák 2017-02-13 09:57:17 UTC
> 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.

Comment 4 Nikolai Sednev 2017-02-13 10:17:09 UTC
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

Comment 5 Doron Fediuck 2017-02-14 14:45:56 UTC
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.

Comment 6 Martin Sivák 2017-09-04 10:49:17 UTC
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.

Comment 7 Martin Polednik 2017-09-04 10:58:49 UTC
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).

Comment 8 Yaniv Kaul 2017-11-16 14:21:17 UTC
(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?

Comment 9 Simone Tiraboschi 2017-11-20 09:25:26 UTC
(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.

Comment 10 Yedidyah Bar David 2017-11-20 10:37:32 UTC
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?

Comment 11 Yaniv Kaul 2017-11-20 10:49:24 UTC
(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?

Comment 12 Yedidyah Bar David 2017-11-20 11:08:13 UTC
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?

Comment 13 Yedidyah Bar David 2017-11-20 11:18:43 UTC
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.

Comment 14 Martin Polednik 2017-11-20 11:33:15 UTC
(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

Comment 15 Martin Perina 2018-02-01 10:01:25 UTC
I've created BZ1540907 and BZ1540909 to fix that issue in engine and aaa-jdbc

Comment 16 Nikolai Sednev 2018-03-18 15:31:00 UTC
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

Comment 17 Yaniv Lavi 2018-06-06 12:31:28 UTC
Closing old RFEs. Please reopen if needed.
Patches are welcome.


Note You need to log in before you can comment on or make changes to this bug.