Seed random on init #2461
Seed random on init #2461
Conversation
Signed-off-by: Derek McGowan <[email protected]>
dmcgowan
force-pushed
the
seed_rand
branch
2 times, most recently
from
108ab14 to
2e37b07
Compare
Signed-off-by: Derek McGowan <[email protected]>
Signed-off-by: Derek McGowan <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #2461 +/- ##
=======================================
Coverage 45.04% 45.04%
=======================================
Files 92 92
Lines 9424 9424
=======================================
Hits 4245 4245
Misses 4496 4496
Partials 683 683
Continue to review full report at Codecov.
|
|
Code LGTM. Do we want to add a note in the docs that specifies a hard minimum kernel of 3.17? We recommend 4.x in general and 3.18 for btrfs which seems fine to me but I wasn't sure if we wanted to be specific. |
|
LGTM |
The hard requirement being for the getrandom syscall? I am not too concerned with it failing as UnixNano() can provide sufficient entropy. The additional random is just to fill in more entropy when it can. |
|
LGTM |
| @@ -0,0 +1,38 @@ | |||
| /* | |||
There was a problem hiding this comment.
I don't think this belongs in pkg, as it is not really reusable.
There was a problem hiding this comment.
not really reusable
Or not useful? After some more discussion might update this package to seed on init and import where seeding might be necessary. Seeding is kind of a complicated issue because it has a global effect and normally that burden is put on importers. Maybe we should just fully encapsulate the non-crypto rand and have a package level seed. Not sure, ideas welcome to make this more useful and non-opinionated.
|
Was |
I am not sure I fully understand what causes a system to have no entropy. Whether a system problem or not, the lack of entropy was causing containerd to hang on startup even though no entropy is required and no cryptographic operation is required to startup. The low entry environments will still have issues pulling images, but those can hang/block until it has enough entropy to proceed. |
There are plenty of broken systems that would probably run into this (i.e. VMs where the hypervisor is misconfigured and the RNG isn't being properly exposed), but there are also plenty of properly-working systems where this is an issue - especially in the low-cost/embedded bare-metal space.
The most common cause for me and my particular use-case is that the system has just booted and has no HWRNG, so it takes a few seconds for the kernel's other entropy-gathering mechanisms to do anything, and 2+ minutes to gather enough entropy for the CRNG to be initialized. See #2451 and linked issues in LinuxKit for more details. |
We switched to using
math/randfor generating IDs but currently it is only being seeded as a side effect of importingstringidfromdocker/docker. ForctrI don't think anything will be seeding random. By default, without seedingmath/randat all, all global calls will use a rand seeded by1.