right now. new address-of-packed-member and format-overflow
warnings have new GCC_NO_ADDR_OF_PACKED_MEMBER amd
GCC_NO_FORMAT_OVERFLOW variables to remove these warnings.
apply to a bunch of the tree. mostly, these are real bugs that
should be fixed, but in many cases, only by removing the 'packed'
attribute from some structure that doesn't really need it. (i
looked at many different ones, and while perhaps 60-80% were
already properly aligned, it wasn't clear to me that the uses
were always coming from sane data vs network alignment, so it
doesn't seem safe to remove packed without careful research for
each affect struct.) clang already warned (and was not erroring)
for many of these cases, but gcc picked up dozens more.
Use sigaction() without SA_RESTART -- signal() implies SA_RESTART so
we never got the EINTR.
While here, reduce the timeout to something more reasonable so we
don't waste 20min of testbed time if anything goes wrong and the
one-second alarm doesn't fire.
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
In a private email, Miloslav had agreed that if they had written the
test, then it can be licensed bsd-2-clause. I am going to assume this
is true as the file names Miloslav as the author.
This test was likely sent to tcsh (not netbsd) that had changed bug
report systems since.
stalled indefinitely in trap instruction even after PT_CONTINUE.
For powerpc, program counter is not automatically incremented by trap
instruction. We cannot increment PC in the trap handler, which breaks
applications depending on this behavior, e.g., GDB.
Therefore, we need to pass (PC + 4) instead of (void *)1 (== PC) to
PT_CONTINUE when child process traps itself.
division by zero is not correctly trapped for i386 and amd64:
https://bugs.launchpad.net/qemu/+bug/1668041
Make trigger_fpe() cause integer division by zero for x86, and
floating-point one for other architectures. Also, assertions for
si_code in *_crash_fpe tests are commented out for now. They
should be cleaned up after the bug is fixed.
Now, *_crash_fpe tests are working also on powerpc.
Suggested by kamil.
until QEMU bug #1668041 is fixed:
https://bugs.launchpad.net/qemu/+bug/1668041
by which floating-point division by zero is not trapped correctly
both on amd64 and i386.
Skip *_crash_fpe tests on powerpc, where integer division by zero
is never trapped.
t_cabsl source is in t_cabsl.cxx not t_cabsl.cc - the latter
is what bsd.tests.mk defaults to.
This only broke after my commit of share/mk/bsd.dep.mk rev 1.85
but I don't know why it didn't cause a problem previously.
When conversion specifier is not a derivative form of "%s", retrieve
input as 32bit integer, and then convert to string literal. Then we
can avoid interpretation from ASCII code to integer, which is
apparently byte-order depended.
integer one, which is not trapped for powerpc and aarch64.
Note that it is checked in lib/libc/gen/t_siginfo whether integer divide by
zero is interpreted as SIGFPE or not.
Now, all *_crash_fpe tests pass for powerpc, and nothing changes for amd64
at least.
New tests:
- fork_setpgid
- vfork_setpgid
- posix_spawn_setpgid
- unrelated_tracer_fork_setpgid
- unrelated_tracer_vfork_setpgid
- unrelated_tracer_posix_spawn_setpgid
These tests trigger a kernel assert for pg_jobc going negative.
The tests are temporarily skipped.
This logic correctly uses strncpy(3) to fully initialize a fixed-width field, and also ensures
NUL-termination on the next line as other users of the field expect.
Add -Werror=stringop-truncation to prevent build failure, when run with MKSANITIZER=yes.
Error was reported when build.sh was run with MKSANITIZER=yes flag.
Reviewed by: kamil@
==> Provide a much more complete set of setters and getters for different
value types in the prop_array_util(3) and prop_dictionary_util(3)
functions.
==> Overhaul the prop_data(3), prop_number(3), and prop_string(3) APIs
to be easier to use and less awkwardly named, Deprecate the old
awkward names, and produce link-time warnings when they are referenced.
==> Deprecate mutable prop_data(3) and prop_string(3) objects. The old
APIs that support them still exist, but will now produce link-time
warnings when used.
==> When the new prop_string(3) API is used, strings are internally
de-duplicated as a memory footprint optimization.
==> Provide a rich set of bounds-checked gettter functions in and a
corresponding set of convenience setters in the prop_number(3) API.
==> Add a new prop_bool_value(3) function that is equivalent to
prop_bool_true(3), but aligned with the new "value" routines in
prop_data(3), prop_string(3), and prop_number(3).
Set SIGPASS for SIGCHLD for the traced child in the following tests:
- unrelated_tracer_fork*
- unrelated_tracer_vfork*
- unrelated_tracer_posix_spawn*
There is a race that SIGCHLD might be blocked during forking and dropped.
PR/55241 by Andreas Gustafsson
mrg