tl;dr The entropy pool is only used during bootstrapping. You only have one kernel which supplies the random numbers. By only having one entropy pool you ensure a higher degree of non-determistic behaviour due to the usage patterns from the jails.
If you trust the algorithms used in
/dev/random then having multiple entropy pools does not give any advantages. It is better to exhaust the common pool quicker and then generate a new (reseed).
No userland programs should use the entropy pool directly. They should always use random(4) and friends.
The longer version with quotes:
The /dev/random device was implemented using the Yarrow implementation between 5.0 and 10.0. It changed to Fortuna in FreeBSD 10. The major upgrade was made in 2014 with revision 273872. There is a little discussion on HackerNews around the time.
rc.d/initrandom was removed with the comments:
Refactor of /dev/random device. Main points include:
Userland seeding is no longer used. This auto-seeds at boot time
on PC/Desktop setups; this may need some tweeking and intelligence
from those folks setting up embedded boxes, but the work is believed
to be minimal.
An entropy cache is written to /entropy (even during installation)
and the kernel uses this at next boot.
An entropy file written to /boot/entropy can be loaded by loader(8)
Remember then that the jailhost is only running one kernel for the system and then the userland binaries of your choice in the jails. When the same kernel is serving the same jails we then need to ask if it is an advantage to change the entropy for every jail?
This is covered by Xin LI in the discussion when the change went in:
The way a PRNG works is that it uses one or many entropy sources to
"feed" its internal state, and generate a series of pseudo-random
numbers from the internal state via a PRF.
FreeBSD collects entropy from several sources: Ethernet, interrupts,
software interrupts, etc., as well as hardware RNG that is available
to the system, and use all these entropy to derive the internal state
of its PRNG.
When reading from /dev/random, one essentially consumes entropy that
is fed into the random device, and eventually it would cause a reseed.
In an ideal world, we would want this to be less predicable and
controllable from a potential attacker.
Normal applications tends to read /dev/random in small bites, and do
so in a discrete and nearly random manner, assuming we have a lot of
processes running. Saving entropy, on the other hand, happen in
larger chunks at a determined time. With multiple jails running, one
would have a lot of big chunk reads from the /dev/random device,
making its behavior more deterministic, which could have bad consequences.