Make supportable promises. Omit needless verbiage. Give caveats
with cross-references to entropy(7). Emphasize that security is
necessarily relative to system configuration.
XXX pullup-10
We no longer block indefinitely -- if nothing else, the hardclock
timer should yield enough samples to unblock /dev/random on all but
the most severely deterministic machines -- so it should be generally
safe for availability to set entropy=wait.
This doesn't guarantee that HWRNG/seed has been provided before you
run ssh-keygen or call getentropy(3) in a user application, but it
does raise the security above netbsd<=9.
PR security/55659
PR lib/56905
XXX pullup-10
- BUGFIX: Fix race condition in openpam_ttyconv(3) when used with
expect scripts.
- BUGFIX: In openpam_set_option(3), when removing an option, properly
decrement the option count.
- BUGFIX: In openpam_subst(3), avoid incrementing past the end of the
template.
Don't test whether a non-blocking read from /dev/random would return
data.
For the sake of availability, /dev/random will unblock based on sources
like timer interrupts, which we can't confidently assert anything about
the actual unpredictability of.
Here, the goal is to highlight systems that have neither obtained
entropy from an HWRNG with a confident entropy assessment, nor been
seeded from a source the operator knows about.
XXX pullup-10
The system will (in a subsequent change) by default block for this
condition before almost all of userland is running (including
/etc/rc.d/sshd key generation). That way, a never-blocking
getentropy(3) API will never return any data without at least
best-effort entropy like netbsd<=9 did to applications except in
single-user mode (where you have to be careful about everything
anyway) or in the few processes that run before a seed can even be
loaded (where blocking indefinitely, e.g. when generating a stack
protector cookie in libc, could pose a severe availability problem
that can't be configured away, but where the security impact is low).
However, (in another subsequent change) we will continue to use
_only_ HWRNG driver estimates and seed estimates, and _not_
time-delta estimator, for _warning_ about security in motd, daily
security report, etc. And if HWRNG/seed provides enough entropy
before time-delta estimator does, that will unblock /dev/random too.
The result is:
- Machines with HWRNG or seed won't warn about entropy and will
essentially never block -- even on first boot without a seed, it
will take only as long as the fastest HWRNG to unblock.
- Machines with neither HWRNG nor seed:
. will warn about entropy, giving feedback about security;
and
. will avoid returning anything more predictable than netbsd<=9;
but
. won't block (much) longer than netbsd<=9 would (and won't block
again after blocking once, except with kern.entropy.depletion=1 for
testing).
(The threshold for unblocking is now somewhat higher than before:
512 samples that pass the time-delta estimator, rather than 80 as
it used to be.)
And, of course, adding a seed (or HWRNG) will prevent both warnings
and blocking.
The mechanism is:
1. /dev/random will block until _either_
(a) enough bits of entropy (256) from reliable sources have been
added to the pool, _or_
(b) enough samples have been added from any sources (512), passing
the old time-delta entropy estimator, that the possible
security benefit doesn't justify holding up availability any
longer (`best effort'), except on systems with higher security
requirements like securelevel=2 which can disable non-HWRNG,
non-seed sources with rndctl_flags in rc.conf(5).
2. dmesg will report `entropy: ready' when 1(a) is satisfied, but if
1(b) is satisfied first, it will report `entropy: best effort', so
the concise log messages will reflect the timing and whether in
any period of time any of the system might be relying on best
effort entropy.
3. The sysctl knob kern.entropy.needed (and the ioctl RNDGETPOOLSTAT
variable rndpoolstat_t::added) still reflects the number of bits
of entropy from reliable sources, so we can still use this to
suggest regenerating ssh keys.
This matters on platforms that can only be reached, after flashing
an installation image, by sshing in over a (private) network, like
small network appliances or remote virtual machines without
(interactive) serial consoles. If we blocked indefinitely at boot
when generating ssh keys, such platforms would be unusable. This
way, platforms are usable, but operators can still be advised at
login time to regenerate keys as soon as they can actually load
entropy onto the system, e.g. with rndctl(8) on a seed file copied
from a local machine over the (private) network.
4. On machines without HWRNG, using a seed file still suppresses
warnings for users who need more confident security. But it is no
longer necessary for availability.
This is a compromise between availability and security:
- The security mechanism of blocking indefinitely on machines without
HWRNG hurts availability too much, as painful experience over the
multiple years since I made the mistake of introducing it have
shown. (Sorry!)
- The other main alternative, not having a blocking path at all (as I
pushed for, and as OpenBSD has done for a long time) could
potentially reduce security vs netbsd<=9, and would run against the
expectations set by many popular operating systems to the severe
detriment of public perception of NetBSD security.
Even though we can't _confidently_ assess enough entropy from, e.g.,
sampling interrupt timings, this is the traditional behaviour that
most operating systems provide -- and the result here is a net
nondecrease in security over netbsd<=9, because all paths from the
entropy pool to userland now have at least as high a standard before
returning data as they did in netbsd<=9.
PR kern/55641
PR pkg/55847
PR kern/57185
https://mail-index.netbsd.org/current-users/2020/09/02/msg039470.htmlhttps://mail-index.netbsd.org/current-users/2020/11/21/msg039931.htmlhttps://mail-index.netbsd.org/current-users/2020/12/05/msg040019.html
XXX pullup-10
The previous prefix 'DK_' (declaration level kind) had a conflict with
the 'DK_' (designator kind) in init.c, so change the prefix to 'DLK_'.
The new name for dinfo_t is decl_level, which is more expressive.
No functional change.
The support for unnamed struct/union members that was added in decl.c
1.60 from 2015-10-13 was simple but wrong. It didn't cover initializers
of these structures and computed wrong sizes for structures containing
anonymous unions. At that time, the handling of initializers was broken
as well, it was fixed 6 years later in init.c 1.229 from 2021-12-22.
Real-life examples for code that lint couldn't handle are:
* external/bsd/jemalloc/dist/src/jemalloc.c
* external/mit/xorg/lib/dri.old/Makefile
When bit-fields in packed structs were added on 2009-10-02, lint assumed
that they would only use 'signed int' or 'unsigned int' as storage unit,
even though C99 also allows _Bool.
The cleanup commit for decl.c 1.225 from 2021-08-28 accidentally changed
the rounding mode for bit-field storage units from round-up to
round-down.
Restore part of local modifications r. 1.2 & 1.4 from tsarna@. One
aspect could not be carried forward, as Apple dropped the bug detection
query functionality that was formerly represented by the teststate
member of the DNSServer struct. Otherwise, reapplied almost verbatim,
except for minor consistency and style changes.
This was added again in part as an example should there be a need to
add further logging content for NetBSD's purposes. (DumpStateLog() has
changed further as of Apple's 1790.80.10 release, but should we roll
forward, our means here should still be viable.)
Add details about the header structure (though the if_npflog.h file is
not presently installed and has a _KERNEL guard). Also adjust some
sentences (requested by riastradh@), and include the original OpenBSD
RCS ID, since much of this content shares that origin.
Previously, primary bootstrap was able to boot on RAID-1 RAIDframe set
with the limitation that the FFS filesystem had to start at bloc 0 in the
RAID. That allowed inner RAID partitionning with a disklabel, but not with
a GPT.
When booting on a RAID-1 RAIDframe, primary bootstrap now first try a
filesystem at bloc 0 of the RAID as before. On failure, it tries to
read a GPT and load secondary bootstrap from, by priority;
1) the first partition with the bootme attribute set
2) the first partition of type FFS, LFS, CCD or CGD
3) the first partition present in the GPT
Only print the debug message if the diagnostic is active, which is
relevant for c99ism, c11ism and gnuism.
Print more details about the diagnostic or query.
nia