(Why is this here? Seems like it should be a .mk fragment under
crypto/external/bsd/heimdal -- that way I would have found it for the
previous commit.)
PR lib/57406
XXX pullup-10
Use .example TLD, per IETF RFC 2606.
Use 192.0.2.0/24, per IETF RFC 5737.
Use 127.0.0.1/24 for localguest, not network that ftp.NetBSD.org used to be in.
PPS_SYNC requires NTP, but some code blocks are ifdef'ed without it,
thus allowing an attempt to build kernel with PPS_SYNC, and without NTP
(and it almost builds with one line change).
Update options(4) man page to reflect the change.
Solution suggested by riastradh.
However, unfortunately, it does not work even if MAXTSIZ is bumped.
It seems to be too large for 24-bit address space.
This is not a regression; gdb.old does not work also.
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.
Addresses PR misc/57441 from Taylor R Campbell. (Not yet hooked into
source sets, will be done separately.)
(Borrows heavily from the equivalent pflog.4 man page already in tree,
and so retains the original copyright attribution as well.)
protected with spec_io_enter()/spec_io_exit() so there is no need
to force specific vnode locking.
Set locking requirement to '= = =' (unchanged, locked or unlocked).
PR kern/57450 (unplugging hung USB disk triggers panic via _vstate_assert)
Add more variables from build.sh, BUILDING, and various
Makefile's documentation:
CDEXTRA CONFIGOPTS KERNARCHDIR KERNCONFDIR
KERNOBJDIR KERNSRCDIR LOCALTIME
Default sentences now consistently end with ".".
Consistency tweaks in "otherwise".
Editorial tweaks.
Add more variables from BUILDING:
INSTALLBOOT_BOARDS INSTALLWORLDDIR NOCLEANDIR
NODISTRIBDIRS NOINCLUDES.
Add build.sh related notes (from BUILDING).
Clarify "target" as "target architecture" where appropriate
(versus a make target where that's obvious from context.)
Move all obsolete and deprecated variables to
new "OBSOLETE VARIABLES" section at the end.
Add some per-variable editorial improvements from BUILDING.
Change sub headings to headings; it's easier to read.
(I don't know why mdoc doesn't allow blank lines around .Ss)
Add more messages for various sets operations.
Add ${_MKMSG_CREATE} to bsd.own.mk.
Enhance maketars to be a bit more verbose even with -q,
to make it more obvious why certain operations may be slow.
May help debugging PR 47562.
Sync user variables from mk.conf(5), sorted.
(Arguably this could just refer to mk.conf(5)
or share/man/man5/mk.conf.5 and remove the copypasta.)
Document NOxxx overrides in own subsection.
Unexpand tabs, tweak after.
MKDTB and MKPIE are .YorN.
MKX11=yes wants MKINET6=yes.
MKLINKLIB deserves a dash list (like bsd.README).
Expand per bsd.README: MKSTATICPIC, MKUNPRIVED,
MKX11, MKZFS, USE_LIBCSANITIZER, USE_SSP
Change the width of the variable lists to 14n (from 15n)
so that when the lists are rendered and then left aligned,
the column is 16 characters (aka 2 tabs) which makes
copypasta to bsd.README easier.
Rename compiler-warning-disable variables from
GCC_NO_warning
to
CC_WNO_warning
where warning is the full warning name as used by the compiler.
GCC_NO_IMPLICIT_FALLTHRU is CC_WNO_IMPLICIT_FALLTHROUGH
Using the convention CC_compilerflag, where compilerflag
is based on the full compiler flag name.
Provide a single variable
CC_WNO_ADDRESS_OF_PACKED_MEMBER
with options for both clang and gcc, to replace
CLANG_NO_ADDR_OF_PACKED_MEMBER
CC_NO_ADDR_OF_PACKED_MEMBER
GCC_NO_ADDR_OF_PACKED_MEMBER
Using the convention CC_compilerflag, where compilerflag
is based on the full compiler flag name.
MKLLD, MKLLDB, MKMCLINKER aren't used in the build,
so remove them.
These were obsoleted by joerg@ on 2019-11-11
with the update of LLVM to 10.0.0git (01f3a59).
For MK* variables (in _MKVARS.yes), default to
MK*.${MACHINE} if MK*.${MACHINE_ARCH} isn't defined.
Equivalent to _MKVARS.no change by mrg@ in rev 1.1065 on 2018-06-16.
Create _NOVARS for the list of NO* variables,
for consistency with _MKVARS.yes and _MKVARS.no
Format _NOVARS, _MKVARS.yes, and _MKVARS.no with
one entry per line, and sort the lists.
Simplifies review and adding new entries.
Per suggestion from riastradh@
Line up some variable assignments more consistently.
It's expressed as an integer, and is also returned as an integer type
should one retrieve it via sysctl(3) (as this man page already
correctly documents in the table above its description).
Add "CC_" prefix to NO_ADDR_OF_PACKED_MEMBER.
We now have the following convention:
GCC_NO_*: Disable specific warnings from GCC.
CLANG_NO_*: Disable specific warnings from Clang.
CC_NO_*: Disable specific warnings from both Clang and GCC.
This reserves "NO_*" Makefile variables to disable other features.
Some space->tab fixes.
List the NO variables in order, leaving enough room to add more entries,
not splitting the next letter after "NO" across a line.
No functional change; just prettier and easier to review.
Remove the leftover remnants of deprecated USE_COMBINE and NOCOMBINE,
as gcc -combine has been EOL for many years.
Completes the work done by maya@ on 2019-05-10 in bsd.kmodule.mk rev 1.61.
Hasn't worked for at least 20 years (and never in the cross-build environment,
nor did it work with parallel make), and has never been needed in NetBSD as we
don't have the older BSD programs (pascal, pre-nvi ex) that needed mkstr/xstr
on PDP-11.
PR toolchain/35964
This allows a caller to grab some data, consume part of it, and
atomically update the uio with only the amount it consumed. This
way, the caller can use a buffer of a size that doesn't depend on how
much it will actually consume, which it may not know in advance --
e.g., because it depends on how much an underlying hardware tty
device will accept before it decides it has had too much.
Proposed on tech-kern:
https://mail-index.netbsd.org/tech-kern/2023/05/09/msg028883.html
(Opinions were divided between `uioadvance' and `uioskip'. I stuck
with `uioskip' because that was less work for me.)
man0 creates files, so write to the the OBJDIR instead of the
source directory.
Use TOOL_ appropriately.
Add MAKEVERBOSE support.
Add separate rules to generate:
- all.files: the list of all man files to process (based on mkman)
- manNpages.files: per-section files from all.files. (based on mkman)
- manNpages.ps: per-section .ps from manNpages.files, with
per-file MAKEVERBOSE messages to stderr (as before, just prettier).
- manNpages.pdf: per-section .pdf from manNpages.ps.
Remove the now-obsolete mkman script.
Add TOOL_GROPS and _MKSHMSG_FORMAT to <bsd.own.mk>
OpenSSL protects the symbols in the shared object via a linker
script, but programs and tests need those protected symbols, so
they either must link against the archive, or I need to expose the
symbols. For now, I chose to expose the symbols. Note that we
cannot use -Bstatic -Lpath -llibrary -Bdynamic because this seems
to be broken with collect2 and so we use the path directly.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.
It was formerly known as mntzz, which Alain released three years ago.
Since then, the ZZ9000 had several firmware updates which changed some
hardware interface details rendering the former driver non functional in some
aspects. Also the audio card plug-in ZZ9000AX became available from MNT
Research. Considering the major rewrite of the driver in some areas he
decided to rename it to zz9k(9). The driver consists of several sub-drivers
each addressing different functionality of the MNT ZZ9000 & ZZ9000AX combo
card.
zz9k* is the main card driver and need to be enabled if any of the sub-driver
is enabled. zz9k on its own is not very useful, it only provides a common
zz9kbus for the other sub-drivers to connect to, so only enable it if one of
the zz9k sub-drivers are enabled.
zzfb* represents the graphics driver for the boot console and the dumb
framebuffer for X11 based on WSCONS. ZZFB_CONSOLE option enables the ZZ9000
to become the boot console.
zz* represents the ethernet interface of the ZZ9000. It basically works but
is considered experimental.
zzax* represents the ZZ9000AX audio card driver, audio* attaches to it to
provide audio output and input functionality. The driver is not functional
yet.
zzusb* represents the ZZ9000AX usb driver. It was not implemented yet and
probably never will.
Otherwise if it is empty before we were adding an optargless -d, which
ended up using the next argument (a -Isomething) after the recent change
to xlint.c related to sysroot. This broke using the native tools make
with the cross toolchain (for example typing make in /usr/src/bin/ls)
to build and install a single program.
We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.
Sorting the variables by size would be platform-dependent and thus is
not possible.
Sorting the variables alphabetically may or may not make the code easier
to read, and the example given below that rule doesn't follow it,
otherwise the correct order would be 'eight, eleven, nine, ten,
thirteen, twelve'.
https://mail-index.netbsd.org/tech-userlevel/2023/04/11/msg013749.html
The man page itself is a skeleton/template for now. Please add short
descriptions and xrefs. If the target man page doesn't yet document
relevant __HAVE macros (hi, mutex(9)), please add something there,
possibly in a .Sh IMPLEMENTATION NOTES section.
riastradh