search

hashgraph / hedera-services

Crypto, token, consensus, file, and smart contract services for the Hedera public ledger
Apache License 2.0
313 stars 136 forks source link

Switch to sourcing random numbers from `/dev/urandom` #13841

Open cweagans opened 4 months ago

cweagans commented 4 months ago

Problem

Spinning off a new issue from https://github.com/hashgraph/hedera-services/issues/5364, which was closed.

Right now, we have to run havaged on all of the consensus nodes. If we don't run havaged, /dev/random starts blocking on reads eventually. havaged must be run as a privileged container to be able to feed entropy to the kernel. This is not ideal. We'll also see some minor issues as we move towards more modern ways of orchestrating our containers (where two instances of the havaged container could be running at the same time, which is something that should be avoided).

Additionally, the quality of the entropy that havaged provides is not guaranteed and is sometimes contested (see banner on https://wiki.archlinux.org/title/Haveged for details).

We're adding additional operational complexity and not gaining much from it.

Solution

Start Java with the right flags to read from /dev/urandom instead of /dev/random. This solution was suggested by Leemon in https://github.com/hashgraph/hedera-services/issues/5364#issuecomment-1454327461

Once that's done, we can get rid of havaged and simplify our deployments a bit.

Alternatives

No response

poulok commented 6 days ago

@rbarkerSL Can you please explain how this ticket does not belong on the DevOps-CI Planning Board?

rbarkerSL commented 6 days ago

@rbarkerSL Can you please explain how this ticket does not belong on the DevOps-CI Planning Board?

@poulok I think it probably belongs under performance or release engineerings board since it is more in the scope of how the images in the runners are configured as opposed to being part of the workflows themselves.