Low entropy for Linux containers on Windows host

Docker Desktop
1

Hello,

I’m running a Linux container on Docker for Windows (1.12.0) and I’m having a problem with the entropy pool that is always very low and this causes my application to be slow as hell (the database driver needs entropy to encrypt the user password)!

Is there a way to modify the Docker daemon and force it to use a different entropy source?

I already found this solution: https://github.com/harbur/docker-haveged, but I would prefer not having to rely on another container for entropy as it complicates my setup and installation scripts…

Thanks,

Christian

2

Thanks for reporting, we’ve opened an internal issue to track!

3

Hi, yes currently Docker for Windows does not have a very significant entropy source, unlike Docker for Mac. I am looking into ways to add entropy to resolve this.

4

This should be fixed in the next beta release, which should be early next week.

5

Thanks for the heads up!

6

Any updates? Can you confirm that it’s fixed in the current beta release because I would like to test it?

7

Sorry we delayed the release this week, it should be released next Thursday I believe. Sorry about the delay.

8

Hello,

Could you please confirm that the fix is present in the latest beta?

Thanks,

9

Hello,

Any updates about the release of this fix?

Thanks,

10

@ocafebabe the fix should be available in the betas now. Can you report back if you’re still seeing problems?

11

@friism I did a test with the latest available beta version 1.12.2-beta28 (7813) and the problem is still there!

12

@ocafebabe What hardware are you using? If you’re on very old hardware, it may not have the relevant support.

13

@friism What do you mean by very old? The CPU on this machine is an Intel i7 960…

14

Paging @justincormack…

15

Can you paste the output of

docker run alpine cat /proc/cpuinfo
docker run alpine cat /proc/sys/kernel/random/entropy_avail

Which exact version are you on?

Thanks.

16

There you go:

PS C:\Users\cbourque> docker --version
Docker version 1.12.2, build bb80604, experimental

PS C:\Users\cbourque> docker run alpine cat /proc/sys/kernel/random/entropy_avail
106

PS C:\Users\cbourque> docker run alpine cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel® Core™ i7 CPU 960 @ 3.20GHz
stepping : 5
microcode : 0xffffffff
cpu MHz : 3111.210
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology pni ssse3
cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm
bugs :
bogomips : 6222.42
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel® Core™ i7 CPU 960 @ 3.20GHz
stepping : 5
microcode : 0xffffffff
cpu MHz : 3111.210
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology pni ssse3
cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm
bugs :
bogomips : 6222.42
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel® Core™ i7 CPU 960 @ 3.20GHz
stepping : 5
microcode : 0xffffffff
cpu MHz : 3111.210
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm
bugs :
bogomips : 6222.42
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel® Core™ i7 CPU 960 @ 3.20GHz
stepping : 5
microcode : 0xffffffff
cpu MHz : 3111.210
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm
bugs :
bogomips : 6222.42
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

17

Hmm, your CPU does not support rdrand (or rdseed, but that is even more recent). Looking it up it was released with Ivy Bridge in 2012, while yours was released in 2009.

Will have to think about what other options there are on Windows - on Mac there is a virtual random device we use, but Hyper-V does not support this.

As a temporary measure you can run https://github.com/harbur/docker-haveged which will work while there is network access.

I created a tracker issue here https://github.com/docker/for-win/issues/161

18

Ok thanks a lot for everything! And I’ll make sure to subscribe to the GitHub issue to track the progress…