These tests emit signal from a tracer/parent to the child and verify the
behavior in the case of SIG_BLOCK (masked) and SIG_IGN (ignored).
The signal is not reported by the child process.
These tests pass.
While there, rename for consistency with other tests:
- traceme_sighandler_catch[1-3] -> traceme_sendsignal_handle[1-3]
- traceme_signal_nohandler[1-5] -> traceme_sendsignal_simple[1-5]
Sponsored by <The NetBSD Foundation>
- Move the sysctl initialization code into spectre.c. This way each
variable is local. Rename the variables, use shorter names.
- Use mitigation methods for SpectreV4, like SpectreV2. There are
several available on AMD (that we don't support yet). Add a "method"
leaf.
- Make SSB_NO a mitigation method by itself. This way we report as
"mitigated" a CPU that is not affected by SpectreV4. In this case,
of course, the user can't enable/disable the mitigation. Drop the
"affected" sysctl leaf.
Add:
machdep.spectre_v2.swmitigated
Rename:
machdep.spectre_v2.mitigated -> machdep.spectre_v2.hwmitigated
Change the method string, to combine both the hardware and software
mitigations. swmitigated is set at compile time, hwmitigated can be
set by the user.
Examples:
spectre_v2.swmitigated = 1
spectre_v2.hwmitigated = 0
spectre_v2.method = [GCC retpoline]
spectre_v2.swmitigated = 0
spectre_v2.hwmitigated = 0
spectre_v2.method = (none)
spectre_v2.swmitigated = 1
spectre_v2.hwmitigated = 1
spectre_v2.method = [GCC retpoline] + [Intel IBRS]
are added:
machdep.spectre_v4.mitigated = {0/1} user-settable
machdep.spectre_v4.affected = {0/1} set by the kernel
The mitigation is not enabled by default yet. It is not tested either,
because no microcode update has been published yet.
On current CPUs a microcode/bios update must be applied for SSBD to be
available. The user can then set mitigated=1. Even with an update applied
the kernel will set affected=1.
On future CPUs, where the problem will presumably be fixed by default,
the CPU will report SSB_NO, and the kernel will set affected=0. In this
case we also have mitigated=0, but the mitigation is not needed.
For now the feature is system-wide. Perhaps we will want a more
fine-grained, per-process approach in the future.
There are at least four types of SIGTRAP events:
- software/hardware single step (trace trap)
- software breakpoint
- hardware breakpoint/watchpoint
- kernel event (exec, fork, vfork, vfork-done, lwp-create, lwp-exit)
A program can execute software breakpoint without the context of being
traced and this is a regular crash signal emitting SIGTRAP (TRAP_BRKPT).
Rename original trap_* tests (trap_simple, trap_handle, trap_mask,
trap_handle_recurse and trap_ignore) to segv_* tests and restrict them for
SIGSEGV.
Add new tests: trap_* testing the same scenarios as segv_ ones, however
verifying the software breakpoint trap (SIGTRAP).
Keep the original name of h_segv.c, and extend it for software breakpoint
events.
The purpose of these tests is to verify SIGTRAP kernel paths without the
ptrace(2) context.
All tests pass.
Sponsored by <The NetBSD Foundation>
our older drm doesn't have any support for modern Pascal or
the second version of Maxwell (but not disabled here yet)
but the driver tries to attach on any nvidia gpu.
this should workaround PR#53258, and other issues reported
with modern nvidia chipsets.
XXX: pullup-7, pullup-8.
Adapt the test to be independent from the software breakpoint trap
behavior, whether the Program Counter is moved or not. Just kill the
process after catching the expected signal, instead of pretending to resume
it.
This test passes.
Sponsored by <The NetBSD Foundation>
me to adapt to the new GPIO interrupt interface and support a wider variety
of GPIO pin configuations.
PR kern/51676
(Oops, forgot to "cvs add" these items previously.)
what's going on.
We have now become "upstream", and most of the ipsec-tools development is
done in NetBSD's CVS. However, many distributions still take their
tarballs from SourceForge (which is defunct, and not maintained).
This is a missing part of the previous commit.
While there fix a typo in a newly added comment in the ptrace(2) code.
Sponsored by <The NetBSD Foundation>
traceme_signal_nohandler2 checks emitting SIGSTOP to a traced process
with the PT_CONTINUE operation.
The expected behavior is to simulate a behavior of receiving SIGSTOP,
generating SIGCHLD to its parent (in this case the debugger) and ability
to call wait(2)-like function receiving the stopped child event.
The previous behavior was unstopping the process and it has been adjusted
in the kernel code.
FreeBSD keeps unstopping a process for emitting SIGSTOP.
Linux handles this scenario in the same way as NetBSD now.
While there, implement the missing bits in the userland ATF test for
traceme_signal_nohandler2: receiving and validating 2nd SIGSTOP event and
continuing the process, followed by its normal termination.
Sponsored by <The NetBSD Foundation>
From dave0 in #NetBSD on Freenode circa December 2017.
Tested in a 32-bit userland harness to produce identical results as old
code for one set of inputs.
