This way, whenever /etc/security runs infrequently (daily), or the
operator manually issues rndctl -S, we ensure that all samples taken
during the entire boot are hashed together in the seed for the next
boot.
This should be infrequent enough that it's unlikely to enable the
iterative-guessing attacks that we try to mitigate by not frequently
consolidating entropy.
Go back to the book's order, now that writing to /dev/random
guarantees to consolidate entropy -- this way the _next_ boot is no
less secure than the current boot, in the event that entropy sources
like interrupt timings provided any security that we just don't know
how to measure honestly.
Make sure to open the old seed to overwrite and the new seed to write
anew first so that we can determine whether the medium is read-only
before accepting the file's entropy estimate.
- Teach rndctl to load the seed, but treat it as zero entropy, if the
medium is read-only or if the update fails.
- Teach rndctl to accept `-i' flag instructing it to ignore the
entropy estimate in the seed.
- Teach /etc/rc.d/random_seed to:
(a) assume nonlocal file systems are unsafe, and use -i, but
(b) assume / is safe, even if it is nonlocal.
If the medium is nonwritable, leave it to rndctl to detect that.
(Could use statvfs and check for ST_LOCAL in rndctl, I guess, but I
already implemented it this way.)
Treating nonlocal / as safe is a compromise: it's up to the operator
to secure the network for (e.g.) nfs mounts, but that's true whether
we're talking entropy or not -- if the adversary has access to the
network that you've mounted / from, they can do a lot more damage
anyway; this reduces warning fatigue for diskless systems, e.g. test
racks.
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). Take whichever byte order gives a number that is
reasonable, i.e. lower than the number of bits in the buffer.
Continue to have `rndctl -S' generate it in machine-dependent byte
order for now, so that if you roll back to an older rndctl(8) then
`rndctl -L' on the same machine will still be able to load it with
the right entropy estimate. In a future revision, perhaps we can
change it to be little-endian.
boot.c:150:29, left shift of 255 by 24 places cannot be represented in type 'int'
boot.c:153:29, left shift of 255 by 24 places cannot be represented in type 'int'
From FreeBSD: https://reviews.freebsd.org/D23082:
Correct off-by-two issue when determining FAT type.
In the code we used NumClusters as the upper (non-inclusive) boundary
of valid cluster number, so the actual value was 2 (CLUST_FIRST) more
than the real number of clusters. This causes a FAT16 media with
65524 clusters be treated as FAT32 and might affect FAT12 media with
4084 clusters as well.
To fix this, we increment NumClusters by CLUST_FIRST after the type
determination.
- Partially sort the list of per-vnode namecache entries by using a TAILQ.
Put the real name to the head, and put dot and dotdot to the tail so that
cache_lookup_reverse() doesn't have to consider them.
no need to skip a prefix "0x" of output of snprintb.
ifconfig expect the result of snprintb has "0x" prefix, but snprintb(3) specification has changed
so that if 0 is passed, it prints "0" instead of "0x0". (common/lib/libutil/snprintb.c r1.22)
christos