Changing the global entropy lock from IPL_VM to IPL_SOFTSERIAL meant
it went from being a spin lock, which blocks preemption, to being an
adaptive lock, which might sleep -- and allow other threads to run
concurrently with the softint, even if those threads have softints
blocked with splsoftserial.
This manifested as KASSERT(!ec->ec_locked) triggering in
entropy_consolidate_xc -- presumably entropy_softintr slept on the
global entropy lock while holding the per-CPU state locked with
ec->ec_locked, and then entropy_consolidate_xc ran.
Instead, to protect access to the per-CPU state without taking a
global lock, defer entropy_account_cpu until after ec->ec_locked is
cleared. This way, we never sleep while holding ec->ec_locked, nor
do we incur any contention on shared memory when entering entropy
unless we're about to distribute it. To verify this, sprinkle in
assertions that curlwp->l_ncsw hasn't changed by the time we release
ec->ec_locked.
This is no longer ever taken in hard interrupt context, so there's no
longer any need to block interrupts while doing crypto operations on
the global entropy pool.
Otherwise, there is a window during which interrupts are running, but
the softint is not, so if many interrupts queue (low-entropy) samples
early at boot, they might get dropped on the floor. This could
happen, for instance, with a PCI RNG like ubsec(4) or hifn(4) which
requests entropy and processes it in its own hard interrupt handler.
This way, we never take the global entropy lock from interrupt
handlers (no interrupts while cold), so the global entropy lock need
not block interrupts.
There's an annoying ordering issue here: softint_establish doesn't
work until after CPUs have been detected, which happens inside
configure(), which is also what enables interrupts. So we have no
opportunity to softint_establish the entropy softint _before_
interrupts are enabled.
To work around this, we have to put a conditional into the interrupt
path, and go out of our way to process any queued samples after
establishing the softint. If we just made softint_establish work
early, like percpu_create does now, this problem would go away and we
could delete a bit of logic here.
Candidate fix for PR kern/56730.
define a flag FILTEROP_ISFD that has the meaning of the prior f_isfd.
Field and flag name aligned with OpenBSD.
This does not constitute a functional or ABI change, as the field location
and size, and the value placed in that field, are the same as the previous
code, but we're bumping __NetBSD_Version__ so 3rd-party module source code
can adapt, as needed.
NetBSD 9.99.89
The previous fix for PR kern/55458 changed printf to log(LOG_DEBUG, ...) with
the intent of hiding the message unless 'boot -x'. But this did not actually
suppress the message to console as log(LOG_DEBUG, ...) will print to console
if syslogd is not running yet.
So instead, just check for AB_DEBUG flag directly in boothowto, and only
printf the message if it is set.
This does not necessarily indicate a problem -- only x86 and arm pass
a seed from the bootloader anyway -- so it makes for an always-on
warning on some platforms, including all rump kernels, which is not
helpful.
This more or less follows the semantics of the RNDGETESTNUM and
RNDGETESTNAME ioctls to restore useful `rndctl -lv' output.
Specifically: We count the number of time or data samples entered
with rnd_add_*. Previously it would count the total number of 32-bit
words in the data, rather than the number of rnd_add_* calls that
enter data, but I think the number of calls makes more sense here.
Otherwise, two processes both waiting for entropy will dance around
waking each other up (by releasing the rndsource list lock) and going
back to sleep (waiting for entropy).
Witnessed on the armv7 testbed when /etc/security presumably ran
twice over a >day-long test, until the metaphorical plug got pulled:
net/if_ipsec/t_ipsec_natt (509/888): 2 test cases
ipsecif_natt_transport_null: [ 37123.2631856] entropy: pid 1005 (dd) blocking due to lack of entropy
[256.523317s] Failed: atf-check failed; see the output of the test for details
ipsecif_natt_transport_rijndaelcbc: [274.370791s] Failed: atf-check failed; see the output of the test for details
[532.486697s]
...
puffs_lstat_symlink: [ 123442.1606517] entropy: pid 9499 (dd) blocking due to lack of entropy
[ 123442.1835067] entropy: pid 1005 (dd) blocking due to lack of entropy
[ 123442.1944600] entropy: pid 9499 (dd) blocking due to lack of entropy
[ 123442.1944600] entropy: pid 1005 (dd) blocking due to lack of entropy
...
Candidate fix for PR kern/55458. This message is rather technical,
and so is unlikely to be acted on by anyone not debugging the kernel
anyway. Most likely, on any system where it is a real problem, there
will be another (less technical) entropy warning anyway.
Three ways to call:
getrandom(p, n, 0) Blocks at boot until full entropy.
Returns up to n bytes at p; guarantees
up to 256 bytes even if interrupted
after blocking. getrandom(0,0,0)
serves as an entropy barrier: return
only after system has full entropy.
getrandom(p, n, GRND_INSECURE) Never blocks. Guarantees up to 256
bytes even if interrupted. Equivalent
to /dev/urandom. Safe only after
successful getrandom(...,0),
getrandom(...,GRND_RANDOM), or read
from /dev/random.
getrandom(p, n, GRND_RANDOM) May block at any time. Returns up to n
bytes at p, but no guarantees about how
many -- may return as short as 1 byte.
Equivalent to /dev/random. Legacy.
Provided only for source compatibility
with Linux.
Can also use flags|GRND_NONBLOCK to fail with EWOULDBLOCK/EAGAIN
without producing any output instead of blocking.
- The combination GRND_INSECURE|GRND_NONBLOCK is the same as
GRND_INSECURE, since GRND_INSECURE never blocks anyway.
- The combinations GRND_INSECURE|GRND_RANDOM and
GRND_INSECURE|GRND_RANDOM|GRND_NONBLOCK are nonsensical and fail
with EINVAL.
As proposed on tech-userlevel, tech-crypto, tech-security, and
tech-kern, and subsequently adopted by core (minus the getentropy part
of the proposal, because other operating systems and participants in
the discussion couldn't come to an agreement about getentropy and
blocking semantics):
https://mail-index.netbsd.org/tech-userlevel/2020/05/02/msg012333.html
If we don't trust a source, it's unreasonable to trust any entropy it
previously provided, and we don't have any way to undo only the
effects of that source, so just zero our estimate of the entropy in
the pool and start over.
(However, keep the samples already in the pool -- just treat them as
though they had zero entropy and start gathering more.)
There was a low-probability race with the entropy consolidation
logic: calls to entropy_extract at the same time as consolidation is
happening might witness partial contributions from the CPUs when
needed=256, say 64 bits at a time.
To avoid this, feed everything from the per-CPU pools into a
temporary pool, and then feed the temporary pool into the global pool
under the lock at the same time as we update needed.
Now that we consolidate entropy in rndctl -L and equivalent, not just
when the operator chooses, epoch != -1 no longer necessarily means
full entropy -- it just means `time to (re)seed, whether justified by
entropy accounting or by explicit consolidation'.
There is a bug on x86 systems with RDRAND/RDSEED that prevents this
message from appearing at all: it happens so early that consinit has
not run yet, so it just goes into oblivion. Need to fix that some
other way!
The man page for some time has advertised:
Writing to either /dev/random or /dev/urandom influences subsequent
output of both devices, guaranteed to take effect at next open.
So let's make that true again.
It is a conscious choice _not_ to consolidate entropy frequently.
For example, if you have a _slow_ HWRNG, which provides 32 bits of
entropy every few seconds, and you reveal a hash that to the
adversary before any more comes in, the adversary can in principle
just keep guessing the intermediate state by a brute force search
over ~2^32 possibilities.
To mitigate this, the kernel generally tries to avoid consolidating
entropy from the per-CPU pools until doing so would bring us from
zero entropy to full entropy.
However, there are various _possible_ sources of entropy which are
just hard to give honest estimates for that are valid on ~all
machines -- like interrupt timings. The time at which we read a seed
in, which usually happens via /etc/rc.d/random_seed early in
userland, is a reasonable time to gather this up. An operator or
system engineer who knows another opportune moment can always issue
`sysctl -w kern.entropy.consolidate=1'.
Prompted by a suggestion from nia@ to consolidate entropy at the
first transition to userland. I chose not to do that because it
would likely cause warning fatigue on systems that are perfectly fine
with a random seed -- doing it this way instead lets rndctl -L
trigger the consolidation automatically. A subsequent commit will
reorder the operations in rndctl again to make it work out better.
1. When consolidating entropy from per-CPU pools, drop the amount
pending to zero; otherwise the entropy consolidation thread might
keep consolidating every second.
This uncovered a feedback loop with kern.entropy.depletion=1 and
on-demand entropy sources, which is that depleting the pool and then
requesting more from it causes the on-demand entropy sources to
trigger reseed, which causes cprng_fast/strong to request more which
depletes the pool again which causes on-demand entropy sources to
trigger reseed, and so on.
To work around this:
2. Set a rate limit on reseeding (advancing the entropy epoch) when
kern.entropy.depletion=1; otherwise reseeding gets into a feedback
loop when there are on-demand entropy sources like RDRAND/RDSEED.
(By default, kern.entropy.depletion=0, so this mainly only affects
systems where you're simulating what happens when /dev/random blocks
for testing.)
We try to avoid counting the seed file's entropy twice, e.g. once
from the boot loader and once from rndctl via /etc/rc.d/random_seed.
But previously, if you had a /var/db/entropy-file that was deemed to
have zero entropy, that would prevent rndctl -L from _ever_ setting a
nonzero entropy estimate, even if you (say) copy a seed file over
from another machine (over a non-eavesdroppable medium) and try to
load it in with rndctl -L, e.g. via `/etc/rc.d/random_seed start'.
Now we accept the first _nonzero_ entropy estimate from a seed file.
The operator can still always trick the kernel into believing there's
entropy in the system by writing data to /dev/random, if the operator
knows something the kernel doesn't; this only affects the _automated_
seed file loading.
Invokes all on-demand RNG sources. This enables HWRNG driver
developers to use a dtrace probe on rnd_add_data to examine the data
coming out of the HWRNG:
dtrace -n 'fbt::rnd_add_data:entry /args[0]->name == "amdccp0"/ {
...examine buffer args[1] length args[2]...
}'
I must have tested (cold ? (void *)1 : curlwp) but then decided,
after testing, to replace cold by !curcpu_available() -- thinking
that would be a safe change to make, except I forgot to either write
the ! or change the sense of the conditional. OOPS.
Fortunately, we're just using it to print helpful diagnostic messages
in kasserts here, so while we're still cold just use (void *)1 for
now until someone figures out how to make curlwp available earlier on
x86.
(All of the curcpu_available() business is a provisional crock here
and it would be better to get rid of it.)
Use the same mechanism as entropy_request, with a little more
diagnostic information in case anything goes wrong. No need for
LIST_FOREACH_SAFE; elements cannot be deleted while the list is
locked.
This is part II of avoiding percpu_foreach with spin lock held.
The file format was defined with a machine-dependent 32-bit integer
field (the estimated number of bits of entropy in the process that
generated it). Fortunately we have a checksum to verify the order.
This way you can use `rndctl -S' on a little-endian machine to
generate a seed when installing NetBSD on a big-endian machine, and
the kernel will accept it on boot.
Primary goals:
1. Use cryptography primitives designed and vetted by cryptographers.
2. Be honest about entropy estimation.
3. Propagate full entropy as soon as possible.
4. Simplify the APIs.
5. Reduce overhead of rnd_add_data and cprng_strong.
6. Reduce side channels of HWRNG data and human input sources.
7. Improve visibility of operation with sysctl and event counters.
Caveat: rngtest is no longer used generically for RND_TYPE_RNG
rndsources. Hardware RNG devices should have hardware-specific
health tests. For example, checking for two repeated 256-bit outputs
works to detect AMD's 2019 RDRAND bug. Not all hardware RNGs are
necessarily designed to produce exactly uniform output.
ENTROPY POOL
- A Keccak sponge, with test vectors, replaces the old LFSR/SHA-1
kludge as the cryptographic primitive.
- `Entropy depletion' is available for testing purposes with a sysctl
knob kern.entropy.depletion; otherwise it is disabled, and once the
system reaches full entropy it is assumed to stay there as far as
modern cryptography is concerned.
- No `entropy estimation' based on sample values. Such `entropy
estimation' is a contradiction in terms, dishonest to users, and a
potential source of side channels. It is the responsibility of the
driver author to study the entropy of the process that generates
the samples.
- Per-CPU gathering pools avoid contention on a global queue.
- Entropy is occasionally consolidated into global pool -- as soon as
it's ready, if we've never reached full entropy, and with a rate
limit afterward. Operators can force consolidation now by running
sysctl -w kern.entropy.consolidate=1.
- rndsink(9) API has been replaced by an epoch counter which changes
whenever entropy is consolidated into the global pool.
. Usage: Cache entropy_epoch() when you seed. If entropy_epoch()
has changed when you're about to use whatever you seeded, reseed.
. Epoch is never zero, so initialize cache to 0 if you want to reseed
on first use.
. Epoch is -1 iff we have never reached full entropy -- in other
words, the old rnd_initial_entropy is (entropy_epoch() != -1) --
but it is better if you check for changes rather than for -1, so
that if the system estimated its own entropy incorrectly, entropy
consolidation has the opportunity to prevent future compromise.
- Sysctls and event counters provide operator visibility into what's
happening:
. kern.entropy.needed - bits of entropy short of full entropy
. kern.entropy.pending - bits known to be pending in per-CPU pools,
can be consolidated with sysctl -w kern.entropy.consolidate=1
. kern.entropy.epoch - number of times consolidation has happened,
never 0, and -1 iff we have never reached full entropy
CPRNG_STRONG
- A cprng_strong instance is now a collection of per-CPU NIST
Hash_DRBGs. There are only two in the system: user_cprng for
/dev/urandom and sysctl kern.?random, and kern_cprng for kernel
users which may need to operate in interrupt context up to IPL_VM.
(Calling cprng_strong in interrupt context does not strike me as a
particularly good idea, so I added an event counter to see whether
anything actually does.)
- Event counters provide operator visibility into when reseeding
happens.
INTEL RDRAND/RDSEED, VIA C3 RNG (CPU_RNG)
- Unwired for now; will be rewired in a subsequent commit.
riastradh