this introduces 4 new warning disable flags:
CC_WNO_MISSING_TEMPLATE_KEYWORD
CC_WNO_REGISTER
CC_WNO_STRINGOP_OVERREAD
CC_WNO_ARRAY_BOUNDS
and documents them in README.warnings. of these, the string op
and array bounds are both problematic (real bugs) and also spurious
(not real bugs), and the other 2 are mostly temporary for older
3rd party code.
add some new uses of CC_WNO_STRINGOP_OVERFLOW.
fix m68k build for gallium and GCC 12.
the first problem is that this rule:
GDBvn.texi: ${DIST}/gdb/version.in
echo "@set GDBVN $$(${TOOL_CAT} ${.ALLSRC})" > ${.TARGET}
conflicts with the "GDBvn.texi" in the source tree and fail to write
this file with r/o source trees.
the second problem is that gdbserver fails to link because it compiles
the wrong file to create target.o. this seems like a very bad make or
bsd.*.mk bug -- "SRCS= .. target.cc ...", and yet, make manages to
compile the file "target.c" to create target.o, and then the required
symbols the rest of gdbserver needs are missing.
the third problem is that when you make it build the right target.cc,
it wants bfd.h, and gmp.h, and even after solving those issues, i'm
still getting a fourth issue linking gdbserver and thus reverting.
- Nix the entropy stage (cold, warm, hot). Just use the usual kernel
`cold' (cold: single-core, single-thread; interrupts may happen),
and don't make any three-way distinction about whether interrupts
or threads or other CPUs can be running.
Instead, while cold, use splhigh/splx or forbid paths to come from
interrupt context, and while warm, use mutex or the per-CPU hard
and soft interrupt paths for low latency. This comes at a small
cost to some interrupt latency, since we may stir the pool in
interrupt context -- but only for a very short window early at boot
between configure and configure2, so it's hard to imagine it
matters much.
- Allow rnd_add_uint32 to run in hard interrupt context or with spin
locks held, but defer processing to softint and drop samples on the
floor if buffer is full. This is mainly used for cheaply tossing
samples from drivers for non-HWRNG devices into the entropy pool,
so it is often used from interrupt context and/or under spin locks.
- New rnd_add_data_intr provides the interrupt-like data entry path
for arbitrary buffers and driver-specified entropy estimates: defer
processing to softint and drop samples on the floor if buffer is
full.
- Document that rnd_add_data is forbidden under spin locks outside
interrupt context (will crash in LOCKDEBUG), and inadvisable in
interrupt context (but technically permitted just in case there are
compatibility issues for now); later we can forbid it altogether in
interrupt context or under spin locks.
- Audit all uses of rnd_add_data to use rnd_add_data_intr where it
might be used in interrupt context or under a spin lock.
This fixes a regression from last year when the global entropy lock
was changed from IPL_VM (spin) to IPL_SOFTSERIAL (adaptive). Thought
I'd caught all the problems from that, but another one bit three
different people this week, presumably because of recent changes that
led to more non-HWRNG drivers entering the entropy consolidation
path from rnd_add_uint32.
In my attempt to preserve the rnd(9) API for the (now long-since
abandoned) prospect of pullup to netbsd-9 in my rewrite of the
entropy subsystem in 2020, I didn't introduce a separate entry point
for entering entropy from interrupt context or equivalent, i.e., spin
locks held, and instead made rnd_add_data rely on cpu_intr_p() to
decide whether to process the whole sample under a lock or only take
as much as there's buffer space for before scheduling a softint. In
retrospect, that was a mistake (though perhaps not as much of a
mistake as other entropy API decisions...), a mistake which is
finally getting rectified now by rnd_add_data_intr.
XXX pullup-10
This is an undefined behavior in general. Implementation details of
pointer are not defined in C standards; it is not necessarily address
of memory objects.
Pointed out by uwe@. Thanks!!
-Wuse-after-free for GCC 12 is premature. It fires on a common idiom:
newbuf = realloc(buf, size);
p = newbuf + (p - buf);
Let shut this up for GCC 12 (with hoping it gets improved for 13!).
Add #{ .. #} block comments to a long conditional.
Move the CC_flag variables closer to other compiler-related
variables instead of being in the middle of some arch-specific
overrides.
Remove most duplication of variables already documented in mk.conf(5).
Add lists of supported and obsolete mk.conf(5) variables
so that searches in this document at least find them
(as per BUILDING).
Sync text from mk.conf(5) for entries that remain.
Explicitly document DESTDIR and RELEASEDIR.
Replace MKMAN=no antipattern with NOMAN=.
Consistently use "option" versus "flag"; option is more generic,
and may include a flag with an argument.
Clarify BUILDID behaviour with OBJMACHINE, and remove unnecessary sentence.
Use option not flag; option may include a flag with an argument.
Sort MKKDEBUG before MKKERBEROS4.
The substantive impact of this is that it enables MKCTF=yes for Xen
kernels. This is a change because, when building a Xen kernel
(XEN3_DOM0, XEN3_DOMU), MACHINE is set to `xen', not to `i386' or
`amd64', so the conditional never took effect.
(The side effect of setting MKDTRACE=yes when building Xen kernels is
unlikely to matter; that affects module and userland builds.)
PR port-xen/57535
XXX pullup-10
These use atomic load on platforms with atomic 64-bit load, and
seqlocks on platforms without.
This has the unfortunate side effect of slightly reducing the real
times available on 32-bit platforms, from ending some time in the
year 584942417218 AD, available on 64-bit platforms, to ending some
time in the year 584942417355 AD. But during that slightly shorter
time, 32-bit platforms can avoid bugs arising from non-atomic access
to time_uptime and time_second.
Note: All platforms still have non-atomic access problems for
bintime, binuptime, nanotime, nanouptime, &c. This can be addressed
by putting a seqlock around timebasebin and possibly some other
variable -- to be done in a later change.
XXX kernel ABI change -- deleting symbols
Use .Cd for options. Don't use the usual <space><tab>, which is
superfluous in the man page. Paragraph break after the config section
of synopsis, before the C API section.
This uses hard interrupts to check progress of low-priority soft
interrupts, and one CPU to check progress of another CPU.
If no progress has been made after a configurable number of seconds
(kern.heartbeat.max_period, default 15), then the system panics --
preferably on the CPU that is stuck so we get a stack trace in dmesg
of where it was stuck, but if the stuckness was detected by another
CPU and the stuck CPU doesn't acknowledge the request to panic within
one second, the detecting CPU panics instead.
This doesn't supplant hardware watchdog timers. It is possible for
hard interrupts to be stuck on all CPUs for some reason too; in that
case heartbeat(9) has no opportunity to complete.
Downside: heartbeat(9) relies on hardclock to run at a reasonably
consistent rate, which might cause trouble for the glorious tickless
future. However, it could be adapted to take a parameter for an
approximate number of units that have elapsed since the last call on
the current CPU, rather than treating that as a constant 1.
XXX kernel revbump -- changes struct cpu_info layout
Update mk.conf(5) with the rump variables from
- lib/librumpuser/README.compileopts
- sys/rump/README.compileopts
Add cross-references back to mk.conf(5) in those files.
Ensure that the Default: is listed last in a description,
for consistency with the convention in this file.
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
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
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.
christos